Every service dashboard shows healthy metrics while users cannot complete a purchase. How is that possible and what would have detected it?
Show the full answer Hide the answer
What is being tested
Whether you understand that technical metrics measure what you thought to measure, and that the gap is where the embarrassing outages live.
How it happens
Every one of these produces green technical dashboards and a broken product:
- A client-side failure. A JavaScript bundle fails to load or throws; the backend never receives a request, so there is nothing to be unhealthy about. Request rate drops, but if nobody alerts on a drop, nothing fires.
- A third-party script or provider failing. A payment provider silently declining, an analytics script blocking the render.
- A feature flag misconfiguration disabling the checkout button for a cohort.
- An expired certificate on one path, or one client platform.
- A successful response with wrong content. HTTP 200 with an empty product list. Every technical metric is perfect.
- A mobile app release broken for one platform, invisible in a total that is dominated by web.
The common thread: the system is healthy and the product is not. No amount of additional technical instrumentation covers this class, because the failure is in the gap between what the services do and what the user needs.
What would have detected it
A business metric alert. Orders per minute, compared against the same time last week, alerting on a significant drop. One alert catches this entire class of failure, including all the causes nobody imagined.
The implementation details that make it work:
- Compare against history, not a static threshold. Traffic has daily and weekly shape; a fixed number is noisy at night and blind in the afternoon.
- Segment by platform, region, client version and payment method. A total that looks normal can hide iOS being completely broken.
- Alert on rate of change as well as level, to catch a sudden drop before the absolute number looks unusual.
- Set sensitivity to catch partial failure. A 15% drop is a real incident and is rarely alerted on.
- Account for known events — a campaign, a holiday, a sale — or the alert becomes noise and gets ignored.
Real user monitoring, which catches client-side failures the backend never sees.
Synthetic transactions — a scripted purchase running every few minutes from outside — which exercise the full path including the client and third parties.
The organisational failure underneath
Business metrics are usually owned by product, on a dashboard, and technical alerts are owned by engineering. So the metric exists, nobody alerts on it, and the outage is reported by a customer.
Fixing that ownership gap is frequently the highest-value observability change an organisation can make, and it costs nothing but a decision.