Why We Wait for Two Failures Before Calling a Site Down

The obvious design is the wrong one

The naive version of an uptime monitor alerts the instant a single check fails. It sounds responsive. In practice it's a machine for training people to ignore emails.

A request can fail for reasons that have nothing to do with your site: a dropped packet between our server and yours, a DNS resolver having a bad second, a load balancer mid-deploy. None of these mean anything is actually wrong. But if every one of them pages you at 3 AM, you learn to glance at the subject line and go back to sleep — and that's exactly the moment a real, hours-long outage stops getting the reaction it deserves.

The rule

A single failed check is recorded but never announced. Only a second consecutive failure opens an incident and sends an email. One more success closes it and sends the recovery email.

That's the whole mechanism. No sliding windows, no percentage thresholds, no configuration to tune — just: did the last two checks both fail.

What it costs

Detection is slower by up to one check interval. On the default five-minute interval, a real outage is confirmed in roughly ten minutes instead of five. If that's too slow for a site that matters more, the fix isn't a smarter algorithm — it's a shorter interval. Checking every minute instead of every five means worst-case detection drops to about two minutes.

What it buys back

Every email that does arrive means something. Two consecutive failures against a site that was previously up is a real signal, not noise from the network between here and there. That's the trade the whole product is built around: an alert you can actually trust is worth more than one that arrives a few minutes sooner and might be nothing.