The first thing most monitors check is the HTTP status code. It is also the easiest thing for a broken site to get right.
A modern web app can fail in a dozen ways while cheerfully returning 200 OK on every request. The status code tells you the server answered. It tells you almost nothing about whether the answer was any good. If your monitoring stops at the status line, you are watching the single signal your application is most likely to keep green while it falls apart underneath.
Here is the catalog of ways a healthy-looking response hides a real outage, and what it actually takes to catch each one.
The error page that returns 200
When a framework catches an unhandled exception, it usually renders an error page and returns it with a 200, on purpose, so that load balancers and crawlers don't hammer a struggling server with retries. Your user sees "Something went wrong." Your monitor sees a successful request and a green dashboard.
The only way to catch this is to read past the status line and into the body. A check that asserts the page contains the thing you expect (a product name, a known element, the word "Dashboard") and does not contain the thing you fear ("error", "exception", "maintenance") catches the entire class. The response was always sitting there to be read. Most monitoring just never opens it.
The blank page that is technically perfect
The server returns a flawless 200 and a valid HTML shell pointing at a JavaScript bundle. The bundle throws on load. The user stares at a white screen. From the server's side, and from any check that only speaks HTTP, nothing is wrong at all, because the break happens in the browser, after the response your monitor was satisfied by.
This one is genuinely hard, and honesty serves you better than a sales pitch here: catching a client-side render failure means running a real browser, which is heavier and slower than an HTTP check. The pragmatic move most teams miss is to make the invisible visible. Have your frontend write a small "I rendered" marker into the page once it succeeds, so a render failure becomes something even a cheap HTTP probe can see.
The page that is fine, on the page you are not watching
Your homepage is up. Your /checkout endpoint is quietly serving "Payments are temporarily unavailable" behind a polite 200, because the payment provider is down and your code is handling it gracefully. Graceful degradation is good engineering. It is also how you lose a day of revenue while every monitor you own reports green, because the page that broke is not the page you pointed a check at.
The fix is unglamorous and effective: monitor the paths that make you money, not just the front door, and assert that the success state is present rather than that the page merely loaded. A check on /checkout that confirms "Pay now" is on the page knows the difference between working and apologizing. A check that confirms only a 200 does not.
The content that is real, just old
You deployed twenty minutes ago. A CDN edge somewhere is still serving the previous version: old prices, a pulled product, an expired promo code, all wrapped in a perfectly valid 200. The status is healthy. The bytes are stale. Status-code monitoring has no way to know, because being out of date is not an error. It just costs you.
Catching this means asserting on something that changes between versions: a build identifier in a response header, a version field in a JSON payload, a string that should or shouldn't be there yet. You stop asking "did it respond" and start asking "did it respond with the thing I shipped."
The certificate that expires on a Tuesday
This one is not subtle. It is just forgotten, and it takes down giants. On December 6, 2018, an expired certificate inside Ericsson's software knocked roughly 32 million O2 subscribers in the UK offline and cut service for tens of millions of SoftBank customers in Japan, across eleven countries, in a single afternoon. Nobody was attacked. A date simply passed.
A TLS certificate has a hard expiry, and the failure is total and instant the moment it lands. The good news is that it is the most preventable outage on this list. The expiry date is sitting inside the certificate weeks ahead of time, waiting for anything at all to read it and warn you. Watching it is table stakes, and skipping it is how a calendar event becomes an incident.
The site that is up, just unusably slow
Eight seconds to first byte is not an outage by any status code's definition. To the person waiting, it is indistinguishable from one, because they are gone before the page paints. "Up" and "fast enough to use" are different claims, and a monitor that checks only the first is blind to the failure mode that quietly costs the most conversions.
The catch here is cheap: a latency threshold. Decide what "too slow to count as up" means for a given endpoint, and fail the check when a response crosses it. Slow is a kind of down, and it deserves to page you like one.
What good monitoring actually checks
Notice what all six share. The status code is green in every one. The truth is somewhere else: in the body, in a header, in the certificate, in the latency, in a path you weren't watching. A monitor earns its keep by reading those, not by trusting the one number your application is best at faking.
Tallwatch checks status, latency, and response content, and it decides an outage by agreement across regions rather than on a single probe's word. But the larger point outlives any one tool. When you set up a check, do not stop at the status line. Assert on the thing that is actually true when your product works, and you will start catching the outages the green dashboard was always going to miss.