SaaS Latency Spike After an ISP Change
Fabrikam has 250 users in Singapore. Since the ISP circuit was changed two weeks ago, users report Salesforce is slow between 09:00 and 11:00. WARP is deployed on all laptops. DEX shows p95 latency to Salesforce rising from 180 ms to 900 ms for about 40 users, all on the new ISP; latency to Microsoft 365 is unchanged. Traceroute from affected devices shows a long path through an IX in Hong Kong, while unaffected users on the old ISP go via Singapore. The service desk wants to open an ISP ticket immediately. The network team suspects the Salesforce tenant, and the endpoint team wants to reimage laptops. You have DEX live diagnostics, WARP, and Gateway logs, but no packet capture on endpoints. No Cloudflare status incident is open, and the Salesforce status page is green.
1. Describe a triage plan that uses DEX evidence to separate endpoint, application, and network-path causes.
Read the worked answer
Segment before escalating. Compare affected and unaffected users by ISP, WARP version, OS, wired versus Wi-Fi, and time of day. Run DEX synthetic tests to Salesforce and to a control SaaS app from both groups, and run traceroute and live diagnostics from representative devices. If only new-ISP users and only Salesforce degrade, the common factor is the path from that ISP to Salesforce, not the laptops or the tenant. Check Gateway logs for policy changes, blocked probes, or new egress rules, and confirm Cloudflare and Salesforce status. Collect p95 and p99 latency, jitter, loss, and traceroute hops. A 40-user pattern tied to one ISP is not an endpoint pattern, so reimaging is premature.
2. What evidence would you attach to an ISP ticket, and what would you ask the ISP to investigate?
Read the worked answer
Attach affected source prefixes, destination, timestamps, p95 and p99 latency, jitter and loss, and traceroutes from affected and unaffected devices showing the Hong Kong IX detour. Include a comparison to the old ISP and to Microsoft 365 as a control. Ask the ISP to check peering and routing toward the Salesforce destination, whether the new circuit is using a different transit or IX path, and whether traffic engineering changed. In parallel, ask Salesforce support whether it sees latency from that ISP or region. Do not claim the tenant is at fault without a control test. If DEX also shows high endpoint CPU, Wi-Fi retries, or WARP version differences, include that so the ISP is not the only hypothesis.
3. What finding would change your conclusion from network path to Salesforce tenant or to endpoint?
Read the worked answer
Change the conclusion if DEX shows the same latency from unaffected ISPs to Salesforce while Microsoft 365 and other destinations remain normal, which points to the Salesforce tenant or an application-side issue. Change it to endpoint if affected users share a WARP version, OS build, or Wi-Fi profile regardless of ISP, or if DEX shows high CPU, memory pressure, or Wi-Fi retries during the 09:00 to 11:00 window. A control test from a non-WARP device on the new ISP is useful if policy allows: if that device is fast, suspect WARP or endpoint configuration; if it is slow, the path is more likely. Document the test and avoid changing multiple variables at once.