Recovery Needs Only One Success, Not Two

The rule isn't symmetric, on purpose

Opening an incident requires two consecutive failed checks — a deliberate guard against a single network blip triggering a false alarm. Closing that same incident requires only one successful check. Same mechanism, different threshold on each side, and that asymmetry is intentional.

Why the two sides don't match

The cost of a false positive on the way down is a 3 AM email about nothing. The cost of a false positive on the way up is much smaller: reporting a site recovered a few minutes before you'd be fully certain, in the specific case where the very next check would have failed anyway. That's a rare and low-stakes mistake compared to training someone to ignore every alert.

Waiting for two successes to confirm recovery would also mean sitting inside an active incident for longer than the site was actually down — extending the exact thing an uptime monitor exists to minimize.

What this looks like in practice

A site fails two checks in a row, an incident opens and an email goes out. The very next check succeeds, the incident closes, and a recovery email goes out immediately — no waiting for a second confirmation that would just delay news you already have.

The trade this makes

Slightly less certainty on the exact moment of recovery, in exchange for incidents that close as soon as there's real evidence things are working again. Given that the down-side of the rule already errs toward caution, erring the other way on recovery keeps the total time spent "in an incident" as close to the true outage window as the two-check design allows.