Anatomy of an edge incident: how EU-West latency became a checkout outage

It started, as these things usually do, with a support message rather than an alert. A handful of European customers said checkout felt slow. The status page was green. The uptime monitor was green. Nothing in the application logs looked wrong. By the time anyone could reproduce it, the completion rate for EU traffic had already dropped eighteen percent.

The cause was not in the application at all. An edge provider was degrading in one region, and that degradation was quietly working its way down through every system that sat behind it.

The symptom is never where the cause is

A checkout slowdown is a symptom. It can be caused by a slow database, a saturated worker pool, a third-party payment API, or, as in this case, an edge network that is taking longer to route and terminate TLS for one part of the world. The symptom looks identical from inside the application. The cause is several layers up.

Following the latency down

Reconstructed afterwards, the sequence was clean and fast. Each step was a separate signal in a different system, and no single tool saw more than one of them.

1. 14:31Edge response times rising for EU-West traffic
2. 14:33Provider status moves to "investigating elevated latency"
3. 14:34Checkout API p95 climbs from 240ms to 3.4s
4. 14:36EU checkout completion rate drops 18 percent
5. 14:51Uptime monitor finally records a failed request

The interesting number is the last one. The uptime check did not register anything until 14:51, twenty minutes after the edge began to degrade and fifteen minutes after customers were already abandoning carts. A request that takes 3.4 seconds and then succeeds is, to a binary up-or-down check, a success.

Why uptime stayed green

Uptime monitoring answers one question: did the endpoint respond. For a long stretch of this incident, the honest answer was yes. The endpoint responded. It just responded slowly, intermittently, and only for some regions. None of that crosses the threshold that a URL check is built to detect.

The outage was real for twenty minutes before any monitor agreed that it had started.

What to watch instead

The signals that would have caught this earlier were not exotic. They were just spread across systems that no one was watching together:

• The edge provider’s own status feed, which moved before any internal metric
• Latency trend on the checkout API, not just its response code
• Regional segmentation, so a problem affecting one market is not averaged away globally
• Completion rate on the journey itself, as the ground truth of customer impact

None of these are hard to collect. The difficulty is correlation: seeing the provider event, the API latency and the regional drop as one incident with a single cause, rather than four unrelated graphs in four different tools. That correlation is the entire job. Everything else is detail.