Your monitoring says the site is up. Your customers say checkout is broken. Both are right — and the gap between those two statements is where revenue quietly disappears.
The 200 OK illusion
The simplest uptime check asks one question: does the server respond? A ping confirms the machine is reachable; a basic HTTP check confirms it returned a status code. Both are useful — a server that does not answer at all is unambiguously down — but they verify the wrong layer. They tell you the infrastructure responded, not that the application works.
The failure modes that slip straight past a status-code check are depressingly common:
- The error page that returns 200. Many frameworks render their error screen with a success status code. The monitor sees 200 OK; the visitor sees a stack trace.
- The empty shell. The web server happily serves the page template while the backend behind it — database, API, payment provider — is down. The page loads, the content does not.
- The stale cache. A CDN keeps serving yesterday's page or a maintenance placeholder while origin is on fire. From the monitor's perspective, everything is splendid.
- The JavaScript crash. Single-page applications return a perfectly healthy HTML document that renders as a blank screen when a script fails. No HTTP check will ever notice.
- The broken step. The homepage works, the product page works, and the payment step hangs. Uptime: 100%. Orders: zero.
First upgrade: content-match validation
The cheapest meaningful improvement over a status-code check is to assert that the response actually contains what it should — a known phrase, a price element, a footer string. Content matching catches the empty shell, the framework error page and the accidentally deployed placeholder, because none of them contain the text a healthy page contains. It costs almost nothing to run and turns "the server answered" into "the server answered with the right page".
Its limit is that it still checks a single response. It cannot tell you whether a visitor can complete anything.
The real test: synthetic browser journeys
What you ultimately need to know is not "does the page respond" but "can a customer still log in, and can they still pay". The only honest way to answer that is to do what the customer does: drive a real browser through the flow, step by step — open the page, fill in the form, click the button, verify the result.
These synthetic browser journeys catch the entire class of failures that request-level checks are blind to: JavaScript errors, broken form submissions, a third-party payment script that stopped loading, a redirect loop after login. Because they run frequently — WatchControl runs them every 5 minutes — a broken flow is caught within minutes of the deploy that broke it, rather than hours later via a support ticket. And when a journey fails, a screenshot of the failing step shows you exactly what the customer saw, which routinely turns a half-hour of guessing into a ten-second diagnosis.
Beyond the website: protocol-level checks
A business does not run on HTTP alone. Mail has to flow, integrations have to transfer files, and internal systems have to authenticate users. Each of those speaks its own protocol, and each can fail while every website check stays green:
- SMTP — if your mail server stops accepting connections, invoices and password resets silently stop. (Whether that mail is trusted once it flows is a separate, DNS-shaped problem — see what is DMARC.)
- SFTP and SSH — the nightly file exchange with a partner fails quietly, and you find out when the partner calls.
- LDAP — a directory service outage locks staff out of everything that authenticates against it.
- TCP port checks — the generic fallback for any service that should simply be listening.
DNS and TLS belong in the same list: a misconfigured DNS record or an expired certificate takes a service down for users just as thoroughly as a crashed process — browsers show a full-page security warning either way. Certificate lifetimes are also getting shorter, which makes expiry monitoring more pressing, not less; see certificate lifetimes are shrinking to 47 days.
Alert fatigue is a monitoring failure
There is a second way monitoring fails, and it has nothing to do with detection: the tool that emails about everything trains its recipients to read nothing. Once notifications for a slow page sit in the same inbox stream as notifications for a dead checkout, both get skimmed, then filtered, then muted — and the one alert that mattered is discovered on Monday morning.
The fix is an honest severity policy: email is reserved for events that need a human now — a service going down (and coming back up), a login or checkout journey breaking. Everything else waits in the dashboard, prioritised, and arrives in a weekly summary. That is the policy TrustCtrl applies across all its products: ordinary findings never email you; act-now events always do.
Where WatchControl fits
WatchControl covers the whole ladder described above: HTTP availability and response-time monitoring, content-match validation, TCP port checks, protocol monitors for SMTP, LDAP, SSH and SFTP, plus DNS and TLS monitoring — with incident tracking to see what happened when. Synthetic browser journeys run your critical flows, such as login and checkout, every 5 minutes and capture a screenshot on failure. If something goes down, you get an email; when it recovers, you get that too. For the broader philosophy, see know it before your customers do.
Why is a 200 OK response not proof that a website works?
Because 200 OK only confirms that a server returned a response, not that the response is correct or that the application behind it functions. Framework error pages, empty templates served while the backend is down, stale CDN content and JavaScript crashes in single-page apps can all produce a 200 status while the site is unusable for visitors.
What is a synthetic browser journey?
A synthetic browser journey is a monitoring check that drives a real browser through a multi-step user flow — such as logging in or completing a checkout — and verifies each step succeeds. It catches failures that request-level checks miss, including JavaScript errors, broken forms and failing third-party scripts, because it experiences the site exactly as a user does.
What is content-match validation in uptime monitoring?
Content-match validation extends an HTTP check by asserting that the response body contains expected content, such as a known phrase or page element. It catches cases where the server responds with a success status code but serves the wrong thing — an error page, an empty template or a maintenance placeholder.
How do you prevent alert fatigue in monitoring?
Reserve immediate notifications for events that genuinely require action now, such as a service going down or a checkout flow breaking, and route everything else to a dashboard and a periodic summary. When every alert in the inbox is genuinely urgent, people act on alerts instead of filtering them.