The situation is familiar: support is receiving complaints, and every dashboard shows healthy. Servers are up, CPU is fine, error rates are normal, and nobody can find anything wrong.
The monitoring is not broken. It is measuring the wrong layer.
Component health is not service health
Every component can be individually healthy while the journey through them fails: a dependency returning valid but empty responses, a queue draining slower than it fills, a feature flag in an unexpected state.
Health checks that only confirm a process is running answer a much weaker question than anyone assumes.
Measure the journey, not the machine
Instrument the outcomes users care about: logins succeeding, orders completing, searches returning results. These are the signals that go wrong at the same moment the complaints start.
A drop in successful checkouts is unambiguous. Normal CPU across a fleet is not evidence of anything.
Averages conceal the problem
A mean response time stays comfortable while a meaningful minority of requests are far slower. If those requests belong disproportionately to one customer or one region, that group experiences an outage invisible in the aggregate.
Watch high percentiles, and segment by whatever dimension your users actually differ on.
Test the whole path from outside
Synthetic checks that perform a real journey — log in, search, add to basket — from outside your network catch the failures that internal checks structurally cannot: DNS, certificates, CDN configuration, and third-party scripts.
These are unglamorous and they are responsible for a large share of the outages that dashboards miss.
The test of a monitoring setup is not how much it covers. It is whether it went red before support did.
