"It says 100% uptime." "Well, it doesn't work." Two true statements, one gap — and the gap is where your unexplained churn lives.
An application can be fully "up" — servers healthy, uptime checks passing — while users experience real failures, because uptime measures whether the server answers, not whether the product works. Frontend exceptions, failing API calls behind a loaded page, broken flows in specific browsers, degraded third-party services and painful latency all happen on the working side of an uptime check. Closing the gap means monitoring the layers users actually experience: what runs in their browsers, what each endpoint returns, and how fast — measured against what "normal" means for your application.
An uptime check asks one question: did the server return an acceptable response to this request? It is a good question — necessary, cheap, and the right first layer. But hold it against what a user needs for the product to "work":
Uptime verifies step 1 of 6. The other five steps fail independently and invisibly — invisible, that is, to any monitoring that stops at step 1. That is the entire mystery of "up but broken", dissolved: the dashboard and the user are answering different questions.
POST /api/checkout fails — the partial backend failure. Monitoring the front door says nothing about the rooms.The gap persists because its victims are quiet. A user facing an error they cannot explain assumes their WiFi, retries, and — if it still fails — leaves. Reporting requires effort, a channel, and a belief that reporting helps; a competitor's tab requires none of those. The few reports that do arrive are stripped of everything diagnostic: "the site doesn't work" — no error text, no browser, no timestamp, no route.
So the feedback loop teams implicitly rely on — if it were really broken, we would hear about it — is broken precisely where it is needed most. The gap's failures are experienced individually, reported almost never, and accumulate as churn attributed to pricing, competition, or fate. Waiting for reports means waiting for the least reliable sensor in the system.
Each resident has a specific monitor:
Teams that add these layers consistently report the same experience: the first week is uncomfortable — the gap was bigger than assumed — and every week after is calmer, because "healthy" finally means what users mean by it.
When the gap is caused by a provider rather than your own code, is it us or them? covers the first ten minutes.
| The core mismatch | Uptime measures server response; users measure whether the product worked in their browser |
|---|---|
| Steps uptime verifies | 1 of 6: delivery — not execution, API success, speed, third parties, or per-browser behaviour |
| The five gap residents | Frontend failure, per-endpoint failure, slow-as-broken, third-party degradation, segment breakage |
| Why it persists | Victims retry and leave rather than report; the reports that arrive carry no diagnostics |
| Business signature | Green dashboards + unexplained churn + occasional vague "it doesn't work" reports |
| The fix | Monitor each layer: browser errors, per-endpoint checks, latency baselines, vendor feeds, per-browser telemetry |
Because "up" only means the server answers requests. The product can still fail after delivery: JavaScript errors in the browser, specific API endpoints failing behind a loaded page, responses too slow to use, third-party services degrading, or breakage limited to certain browsers. All of these occur on the passing side of an uptime check.
Your monitoring is answering a narrower question than your users are. An availability check verifies delivery; users experience execution, per-endpoint behaviour, speed and third-party dependencies. Failures in those layers — which are the majority of user-facing failures — need their own monitors: browser error collection, per-endpoint checks, latency baselines and vendor status feeds.
Functionally, often yes. Requests that succeed after many seconds pass every status check while users abandon the task. Treat latency at several times an endpoint's own baseline as an incident-grade signal, because that is how users are treating it.
Collect frontend errors with browser-family context attached. Segment-specific failures are invisible to server-side monitoring and to testing on the team's own machines; field telemetry is what converts "works for us" into "failing specifically in this browser family since Tuesday's deploy".
Add browser error collection first — it illuminates the largest unmonitored layer with a single script tag. Then add individual checks with latency baselines on the handful of endpoints behind login, core data and payment, and subscribe your monitoring to your key vendors' status feeds. Those three steps cover most of the gap for most applications.
To your users, yes — they experience your product as broken regardless of whose incident it is. Monitoring vendor status feeds and mapping dependencies lets you respond honestly (status page, in-app notice) and stops your team burning hours debugging code that was never at fault.
Merik is built around exactly this gap. Uptime checks cover the front door; the merik.js snippet watches what actually happens in users' browsers — exceptions, rejections, failed requests, grouped per site and judged against that site's own usual hour, with browser-family context for the segment-specific cases. Per-endpoint checks with content assertions and 14-day latency baselines cover the rooms behind the door, and "slow against its own normal" feeds early warnings with the same seriousness as failure.
Vendor status feeds are integrated and mapped per asset, so a payment-provider outage becomes an explained, suppressed incident instead of a mystery — and instead of forty pages. The result is a health picture that answers the user's question rather than the server's: not "did it respond?" but "is it working?" — and when the two diverge, you hear about it from Merik, not from churn.
The server said 200. The page broke anyway. Seeing the failures uptime checks can't.
The failures nobody notices are the ones that compound. What silence costs, and how to end it.
The first ten minutes, what not to do, honest communication, and shrinking the blast radius.