Your Uptime Monitor Said 99.9%. Your Customers Disagreed.
A 99.9% uptime badge looks like proof nothing went wrong. It’s proof of something much narrower: that a server answered a request quickly enough, often enough. Whether the page it returned actually worked for the person waiting on it is a different question, and most uptime monitoring never asks it.
What uptime monitoring actually measures
A typical uptime check is a request to a URL, usually the homepage, with a timeout and a status code check. Get a response in the 200 or 300 range before the timeout expires, and the check passes. That’s the entire test.
It doesn’t know whether the page rendered correctly, whether a database error replaced the real content with a generic “something went wrong” message that still happened to return a 200 status, or whether the specific page a customer needed, checkout, login, an API endpoint, was actually reachable at all if the check only ever looked at the homepage. “Up” in this context means a server answered, not that the site worked.
The math nobody does on their SLA number
Percentages hide how much time they actually represent. 99.9% uptime over a 30-day month allows for about 43 minutes of downtime and still rounds to the same reassuring figure. 99% allows over seven hours. Only 99.99% gets down to roughly four minutes, and that extra decimal point is doing a lot more work than it looks like on a status page.
None of this is a criticism of the math. It’s a reminder that a headline percentage is compressing a real amount of outage time into a number designed to look good, and it’s worth doing the conversion yourself before deciding whether a given SLA is actually reassuring.
It compounds, too. If your site depends on three separate services, your own server plus two third-party APIs, each individually holding 99.9% uptime, the odds that all three are up at the same moment work out to roughly 99.7%. That’s a little over two hours of potential downtime a month, spread across dependencies you don’t control and probably aren’t monitoring individually, even though each one’s own status page looks fine in isolation.
It’s the same pattern behind Lighthouse score history: a single current number, whether it’s a performance score or an uptime percentage, tells you far less than the trend and the dependencies behind it.
Why the check interval hides real outages
A monitor that checks every five minutes can only ever notice outages that happen to overlap with one of its checks. A genuine outage that starts and resolves in ninety seconds, sitting entirely between two checks, never gets counted, even though real visitors hit it. Reported uptime can look excellent while still missing exactly the kind of short, sharp failure that actually costs a sale or a support ticket.
The same blind spot applies geographically. A check running from a single location says nothing about whether a CDN edge node or a specific region’s routing is failing for a subset of visitors while everything looks fine from where the monitor happens to sit. A site can be fully down for every visitor in one country and still post a clean uptime report, simply because the one server the monitor happens to query never noticed.
Slow isn’t down, but it behaves like it
Most monitors use a generous timeout, sometimes 30 seconds or more, before calling a request failed. A page that takes 8 seconds to respond passes every check comfortably while most visitors have already left. Response time creep is invisible to a binary up-or-down check, which means a site can be technically “up” for its entire monitoring history while quietly getting slower and losing visitors the whole time.
Does 99.9% uptime mean my site is reliable?
No. It means a server answered a basic request often enough to hit that percentage, measured at whatever interval and from whatever location the check happens to use. It says nothing about whether the pages that matter actually worked, how slow “working” was, or whether short outages between checks went uncounted.
A quick self-audit
- Check what your monitor actually tests. A status code check alone doesn’t confirm the page rendered correctly, only that something answered.
- Monitor the pages that matter for revenue, not just the homepage. Checkout, login, and any API your product depends on can fail independently of the front page.
- Know your check interval, and understand that any outage shorter than it can go completely uncounted.
- Track response time as its own metric, not just pass or fail. A site can be “up” and still be too slow for anyone to use.
A status badge that only pings your homepage every few minutes isn’t telling you much. kant.au monitors uptime alongside response time, not just whether something answered within a generous timeout, so a slow, degraded site shows up before it turns into a support ticket. Want a clearer picture than a single percentage gives you? Start a free 14-day trial and find out.