An Outage Is Real When the Regions Agree

From a failed request to an alert

1. 1. Every region checks on its ownEach probe region your monitor uses sends its own request on the monitor's interval and records the result independently. Regions do not share answers, so one region's network trouble cannot leak into another's result.
2. 2. A failure is re-tested before it countsWhen a check from our primary checker fails, it re-tests once about two seconds later, still inside the same interval, before recording the failure. A connection reset that clears in a second never becomes a failed check.
3. 3. Optional: several failures in a rowEach monitor has a failure threshold you can set from 1 to 10 consecutive failed checks (default 1). Raise it for targets that are known to blip; leave it at 1 for the fastest detection.
4. 4. A quorum of regions must agreeAn incident opens only when the required number of live regions report the monitor down at the same time. Each region's vote is its most recent result from the last 10 minutes, or 2.5 times the check interval if that is longer, so slow intervals still line up.
5. 5. Then, and only then, alerts go outOnce the quorum is met the incident opens and your alert channels and escalation policy take over. Maintenance windows, quiet hours and monitor dependencies are applied at this point.

How many regions must agree, per plan

The quorum scales with the number of regions a plan checks from. If you choose fewer locations for a monitor than your plan allows, the quorum is capped at the number you chose.

For example, a Starter monitor is checked from 3 regions. If one of them cannot reach your site but the others can, no incident opens. If 2 of them fail at the same time, it does.

When a probe region is offline

Only regions with a live probe get a vote. If so many of a monitor's regions are offline that the normal quorum can no longer be reached, the monitor is marked as having reduced coverage in your dashboard, and a stricter rule takes over so a real outage is still reported: every remaining region must see the monitor down on consecutive checks (at least 2 each), and the built-in checker must not see it up. Only then does an incident open, and the alert and incident timeline say it was confirmed with reduced coverage. A single failed check from one remaining region never pages anyone.

Checker address changes, which can take a region offline for a short time, are announced on the bot information page.

How recovery is decided

Recovery is deliberately easier than going down: an open incident resolves when a majority of the monitor's live regions see it up again (never more than the down quorum). That way an incident does not stay stuck open just because one region is still offline.

The finer points

• Slow is not downA response that arrives but is slower than your degraded threshold is recorded as degraded, which counts as up for the quorum. Use a maximum response time rule if slow should count as down.
• Heartbeat monitorsCron and heartbeat monitors have no target to probe from a region; they are judged by our servers alone, on whether your job pinged on time.
• FlappingIf a monitor goes down again within 5 minutes of recovering, the repeat alert is held back so a flapping target does not flood your channels. If it then stays down for the full 5 minutes, you are alerted again.
• Regional outagesThe flip side of a quorum: if your site is unreachable from only one region on a multi-region plan, no incident opens. You can still see that region's failed checks on the monitor's page.

The probe regions right now

3 of 3 regions have a live probe at the moment this page was generated (refreshed every few minutes). New locations appear here as soon as their probe comes online.

See it for yourself

Run the free website uptime checker against your own site to see what each region gets, or read the guide on reducing false alerts.