If your uptime dashboard says 99.9%, congratulations. Your server responded to pings 99.9% of the time.
That number says nothing about whether your users could actually use your site.
The monitoring industry has spent two decades optimizing for the wrong metric. We got really, really good at answering "did the server respond?" — and never moved on to the question that actually matters: "does the site work?"
The gap nobody talks about
There's a growing space between what monitoring tools measure and what users actually experience. It's getting wider, not smaller, because modern web architecture is getting more complex.
Ten years ago, your site was a server rendering HTML. If the server was up, the site worked. Uptime monitoring made sense.
Today, your "site" is a document that references hashed JS bundles from a CDN, loads third-party scripts from five different domains, runs through an API gateway, gets assembled by edge functions, and depends on a headless CMS for content. The server responding is step one of a twelve-step process.
Uptime monitoring still checks step one.
What "up" actually looks like in production
Let's say your uptime monitor pings your site every 60 seconds. Here's what it does:
- Sends an HTTP request
- Gets a response
- Checks the status code
- If it's 200, marks the site as healthy
Here's what it doesn't do:
- Check if the JavaScript bundles the page references actually exist
- Verify that assets are served with correct MIME types
- Follow redirect chains beyond the first hop
- Compare the response content to what it looked like yesterday
- Check whether third-party dependencies loaded
- Verify the page works from more than one location
Every single one of those unchecked items is a real failure mode that happens in production regularly. And every single one returns HTTP 200 OK.
Three failure patterns your uptime tool will never catch
The stale CDN.
You deploy. Your CDN edge nodes in some regions still serve old HTML. That HTML references JS bundles that no longer exist. The document loads, the scripts 404, nothing renders. Some users get it, others don't. Your monitor checks from one region and sees a healthy page.
The MIME mismatch.
A misconfigured proxy serves your JavaScript file with Content-Type: text/html. The browser downloads it, reads the header, and silently refuses to execute it. No console error. No failed network request. Just a page that never initializes. Status: 200.
The silent dependency failure.
Your site loads fine. Your payment provider's JS doesn't. The checkout button renders as an empty container. Your page looks complete. It just can't process transactions. Your uptime tool checks your domain — the broken resource is on someone else's.
None of these are edge cases. They're happening on production sites right now. The sites report 99.9% uptime while users experience broken functionality.
Why the industry is stuck
Uptime monitoring became a commodity. Dozens of tools compete on the same feature set: more check locations, faster intervals, prettier dashboards. But they all measure the same thing — did the server respond with a non-error status code.
The underlying assumption hasn't changed since 2005: a healthy HTTP response means a healthy website.
That assumption was wrong then. It's dangerously wrong now.
Part of the reason is that deeper monitoring is harder. Verifying asset integrity means parsing HTML, extracting resource references, and checking each one. Following redirects properly means handling cookie state and user agent differences. Detecting content drift means fingerprinting responses over time. Checking from multiple regions means actually running infrastructure in multiple regions.
It's more expensive to build and more expensive to run. So most tools don't do it.
What would real monitoring look like?
If we started from scratch — knowing what we know about how modern sites actually fail — monitoring would look completely different.
It would treat the HTML document as a manifest, not a destination. The document is the starting point. The real question is whether everything it references actually loads and works.
It would verify, not assume. Instead of trusting that a 200 means everything is fine, it would check that JS bundles return the right MIME type, that redirects resolve instead of loop, that the content hasn't silently changed.
It would check from multiple locations. CDN failures are regional. A site can be perfectly functional in one region and completely broken in another. Single-region checking misses this entirely.
It would distinguish between "responded" and "works." Two fundamentally different states that current monitoring treats as one.
It would reduce noise, not create it. False positives at 3am erode trust faster than anything. A proper confirmation model — checking multiple times before alerting — means you only get woken up for real problems.
This is why we built Sitewatch
We got tired of the gap between what uptime dashboards reported and what users actually experienced. So we built monitoring that checks whether your site actually works — not just whether the server responds.
Sitewatch monitors asset integrity, MIME types, redirect chains, content fingerprints, and multi-region consistency. When something breaks, it classifies the root cause — infrastructure, application, or content delivery — so you know what to fix, not just that something is wrong.
Free tier for 1 site. No credit card. Check it out if you've been burned by a green dashboard that was lying to you.
Uptime was the right metric for a simpler web. The web isn't simple anymore. The monitoring needs to catch up.
Top comments (0)