Their status page is green. Your people cannot work.
You have outsourced the application and inherited the path. When a critical service degrades, the part that is broken is usually not the part either of you is monitoring.
Provider status pages describe the provider's view of the provider's infrastructure. They are generally accurate and almost never useful during the first hour of a problem, because a regional path degradation affecting a subset of customers does not meet the bar for a global status update, and may genuinely not be their fault.
Meanwhile you are being asked whether it is us or them, and the honest answer is that nobody in the building can tell.
Measure the dependency the way you would measure your own service
You would never run a critical internal application with no instrumentation. The fact that this one is somebody else's does not make it less critical; it makes it less observable, which is an argument for more measurement rather than less.
- 01The route
- Per-hop path measurement to the service endpoint, from each site that depends on it. Degradation between your edge and their edge is the most common cause and the least visible, because neither party is monitoring the middle.
- 02Resolution
- DNS timing and the answer itself, over whichever transport your resolvers use. Large providers steer users by DNS, so a site being sent to a distant or unhealthy region shows up here first, and a resolver returning a stale record quickly looks perfectly healthy on a latency graph.
- 03The connection
- Connect, TLS handshake and first byte as separate numbers rather than one total, plus certificate expiry. A handshake that has doubled while transfer stayed constant points somewhere very specific.
- 04The transaction
- An ordered multi-step sequence, because one request against a login page does not tell you that logging in works. Sign in, fetch the record, submit the change, measured as the sequence a person performs.
- 05The experience
- A real browser loading the real application, so you measure what a person experiences rather than what an HTTP request experiences. Single-page applications routinely have fast responses and slow pages.
These run against one target on one schedule and land on one timeline, so a slow page load sits beside the handshake timing and the route that produced it. Correlating them is looking at them, not exporting two systems into a spreadsheet.
The same service is not the same service everywhere
Large providers serve you from whichever edge location your traffic reaches, chosen by routing and DNS rather than by geography. Two of your offices in the same country can be served by different regions over entirely different carriers.
So a single synthetic check from one cloud region tells you the service exists. It tells you nothing about the experience of the office that is actually complaining.
Running the same test from every site that depends on the service turns "is it down" into a map: which locations are affected, which are fine, and therefore whether this is a provider problem or a problem with one path to that provider.
Renewal leverage, incidentally
Contracts with service level commitments are usually enforced on the provider's own measurements, because the customer has none.
A year of continuous, timestamped measurement from your own vantage points changes that negotiation, and it changes the tone of the incident calls before it.
It also settles the internal version of the argument. When somebody proposes migrating away from a service because it is unreliable, you can check whether it is.
Pick the service your business cannot work without
The service is reachable, but the experience is slow.
An illustrative investigation. Follow the evidence from where it was measured to the result you need to explain.
1.Measure from the affected location
Place an agent where the problem is experienced. Compare the same target from another vantage point to see whether the issue is local or shared.
Set up a vantage point2.Separate the path from the application
Use Path Health for the route and HTTP for request timing. Compare DNS, connection, TLS and response phases before deciding which layer to investigate.
Choose your checks3.Inspect the moment that matters
Choose the time window, inspect individual results and read the trust qualifiers. Keep the target and vantage point alongside the evidence.
Read the results