Updated 2026-06-20
Confirmation is the feature that separates Status from a simple uptime pinger. A check doesn't go from "up" to "down" on a single failed probe — it goes through a verification step first.
The problem this solves
Any single monitoring vantage point can have a bad moment: a regional network blip, a transient DNS hiccup, a brief routing issue between that one region and your target. If you alert on every failed probe from every region, you get paged for noise, not outages. Status's answer is to require agreement across regions before it calls something down.
How it's configured
Each check has a confirmations setting — how many distinct regions must agree the check is down before an incident opens. It ranges from 1 (trust a single region's result immediately) up to a plan-dependent maximum. Higher plans allow more regions and shorter confirmation windows, so incidents can open faster without sacrificing accuracy.
What happens on a failure
- A probe reports a failure from its region.
- If
confirmationsis 1, the check goes down immediately. - If
confirmationsis higher, the check enters a pending state and Status asks other regions to independently re-check the same target. - Once enough distinct regions agree it's down, an incident opens and your alert channels fire.
- If the other regions come back up instead, the original failure is recorded as a blip — visible in the check's event history — but no incident opens and no alert fires.
Recovering is faster than failing
Confirming a recovery is deliberately easier than confirming a failure: a
check that needed three distinct down-votes to alert only needs two
up-votes (the original region plus one confirmer) to resolve — or a single
organic success if confirmations is 1. The bias is toward clearing a
resolved incident quickly rather than holding a false outage open.
If a check on your account seems to bounce between up and down rather than settling, see Why is my check flapping? — raising the confirmation count is usually the fix.