It's Monday morning, and support has a queue of customers who can't finish paying. The incident bridge fills up fast. Your APM shows normal latency. The CDN's status page is green. The payment provider reports no incidents, and so does your identity provider. Everyone on the call can show that their part is healthy, but the customer still can't pay. And that's what matters.
That's the hardest kind of outage to run. The question on the bridge is which part is broken, and whose it is. Until someone can answer that with evidence, the first hour of the incident goes to each team proving its own systems are fine.
Every dashboard is telling the truth
Nobody on that call is wrong. Your logs, traces, and metrics accurately describe the systems you run, and good teams have invested heavily in them. The CDN's reporting accurately describes the CDN. The payment provider's status page describes the payment provider. Each view is honest, and each one stops at the edge of the system it measures.
A customer's transaction doesn't stop at those edges. A single complex transaction, such as a checkout, can involve 5 to 50 hand-offs between your services and third parties, across DNS, the network path, the edge, your origin, and APIs running on someone else's infrastructure. The failure the customer feels often lives between two healthy systems: a token one service issues and the next one rejects, a third-party API that answers quickly with the wrong data, an edge rule that misroutes traffic from one region.
Internal telemetry has no customer-impact signal for that gap, because no single system owns it.
The failures that fall between systems
Three kinds of failure land there most often. The first is in authenticated journeys. A health check against a public endpoint tells you the front door opens. It can't tell you whether a signed-in customer can see their account, make a payment, or export their data, and passive discovery only sees the workflows that already carry traffic.
The second is third-party dependencies. Payment, identity, fraud, and messaging services sit inside your most valuable journeys. When one of them degrades, the failure reaches your customer before it reaches your telemetry, if it reaches your telemetry at all.
The third is geography. DNS resolution, routing, and edge configuration differ by region, so a journey that works from your office can fail for customers somewhere else. Testing from one place tells you about one place.
Verification starts where the customer starts
Verification closes the gap by testing the way a customer arrives: from outside your infrastructure, through the public network, the edge, and the sign-in, across every step of the journey. Outside-in API monitoring signs in with test accounts and the credentials you already use (OAuth, API keys, or mTLS), calls each service in order, and checks each response against what you expect. When a step fails, the result shows which step broke and where it failed from.
Run the same journey from many places and the pattern does the first round of triage. We test from 125+ locations across five clouds and six world regions. A failure from every location points toward your origin or a shared dependency. A failure from one region points toward DNS, routing, or the edge there. A failure at the same step every time names the service that owns it.
Because the tests run from our own nodes, the evidence doesn't depend on any one provider's reporting about itself. Everyone on the bridge looks at the same independent record of what the customer experienced.
Evidence decides who acts first
On the bridge, that record replaces the round of each team defending its own dashboard. The failing step and location go straight to the team that owns them, through the alerting you already use, such as Slack, PagerDuty, or webhooks. Results also flow into your observability tools through OpenTelemetry export and official Datadog and Dynatrace integrations, so the customer's view sits beside the telemetry you already trust. Customers report cutting mean time to resolution from hours to minutes.
The evidence keeps working after the incident. When executives or your own customers ask how the service performed, a record of which journeys completed, from where, and when answers the question they're really asking: could people do what they came to do? An uptime percentage answers a narrower one.
Start with one journey that matters, such as login or checkout. Test it end to end from the regions where your customers are, and the next time the bridge fills up, you'll start with the answer to who has the next step to resolve it.