Your dashboard is green. Every check is green. And then a customer emails: "is the site down?"
Both are true. Your monitoring watches the server. Your customer experiences the route between the server and their screen. Here's the gap between the two, and how to close it in under an hour.
Why green dashboards lie
Your uptime checks run from inside your infrastructure. The customer's request travels a longer road: their device, their wifi, their DNS resolver, your CDN, your load balancer, your app, your database, and back. A dashboard checks one link. The customer lives on the whole chain.
Three failure modes a green dashboard can't see:
1. The regional blackout. Your US-East check passes. Your Singapore customers have been getting timeouts for 90 minutes. Nobody inside the datacenter notices, because inside the datacenter everything is fine.
2. The dependency you don't own. Your app is up. The payments provider your checkout depends on is degraded 20% of the time. Your dashboard shows 100%; your customers experience a checkout that fails every fifth attempt — and they don't retry, they leave.
3. The slow bleed. Everything returns 200, but page weight crept up, the third-party analytics script grew, and your load time went from 2s to 9s over three months. No alarm fires, because 200 isn't an error. But your bounce rate is an error, and it's firing.
The 1-hour fix: monitor from the customer's chair
1. One external check, one region you DON'T host in. (15 min) A free synthetic monitor hitting your real URL from another region. Not the health endpoint — a real page. Health endpoints check the server; real pages check the experience.
2. One business-transaction check. (20 min) Add-to-cart, or submit-the-form, on a test account, daily. This is the only check that answers "can a customer actually give us money." It's also the most valuable alarm you will ever build — a failed transaction check is worth a thousand CPU graphs.
3. One page-load budget with an alarm. (15 min) Pick a number — 3 seconds on a real connection — and alert when your key page exceeds it. Speed isn't a feature, it's a silent metric that taxes every visitor.
4. One status line a human wrote. (10 min) When something breaks regionally, a status page that says "investigating" in under 5 minutes converts angry emails into patient waiting. Silence converts them into churn.
None of this needs a tooling budget. It needs the decision that the customer's experience — not the server's health — is the thing you sell.
I packaged the external-check list, the transaction-test template, and the page-load budget worksheet into the Ops Starter Kit — fill-in-the-blanks, no theory. If you'd rather automate checks 1-3 outright, the Automation Starter Pack has the scripts.
Question for the comments: what's the longest an outage ran before anyone noticed? And the follow-up that stings: how did you finally find out — your monitoring, or a customer?
Top comments (0)