Blog · 2026-10-13

How we decide a service is really down

The probe, the content check, the two-failure rule, and why a page that answers 200 can still be an outage.

Every reading on this site starts as an HTTP request one of our servers actually made. That is the whole method, and it is deliberately narrow: if we cannot see it, we do not publish it.

Which request

Each monitored service has a URL, an expected status range, and often a phrase that must appear in the response. For a tax portal that phrase is usually the authority's own name. This matters more than it sounds: a captive portal, a CDN error page, or a "we'll be back soon" screen all answer HTTP 200. A 200 with the wrong content is reported as down, not as a healthy service.

Some error codes mean "alive"

An API that refuses an unauthenticated request with 401 or 400 is working exactly as it should. Those endpoints are configured to treat that specific response as healthy — otherwise every payment API would appear permanently broken.

Two failures before we say down

A single timed-out request is usually a blip on the network between us and the service, not an outage. A service is only marked down after consecutive failed checks. Slowness is treated separately: still answering, but far slower than its own normal, is degraded rather than down.

Then it stays honest on the way back

The first successful check closes the incident, records how long it lasted, and sends a recovery notice to anyone who was alerted. Latency history for the incident is kept so the uptime percentage on a status page is arithmetic over real checks, not an estimate.

What we cannot see

A reachable website can still be broken for you: a login loop, a verification code that never arrives, a payment that fails at the last step. A remote probe cannot detect any of that, which is why every service page also takes reports from the people hitting the problem. How those two signals are combined — and which one is allowed to declare an outage — is the subject of the next post.