Cross-Region Quorum: How Confirmation Stops False Alerts
Cross-region quorum means a target is only called down once probes in more than one region agree. Here is the voting rule, its cost and its limits.
Cross-region quorum is the rule that a target is only called down once probes in more than one region agree that it is. A single region can be wrong about a target for reasons that have nothing to do with the target. One probe's vote is therefore a suspicion, not a verdict.
What does a cross-region quorum actually decide?
A quorum is a threshold on votes. Each region that checks a target casts one vote per check, up or down, and the target's state only changes when the votes clear the threshold. The two rules worth knowing are AND, where every region must agree, and 2-of-3, where any two out of three regions carry the decision.
As of September 2026 the free plan uses a two-region AND, and paid plans use 2-of-3 with the regions selectable from the six available.
| Rule | Regions | Down when | Tolerates |
|---|---|---|---|
| 2-region AND | 2 | both fail | nothing, one dissent keeps it up |
| 2-of-3 | 3 | any two fail | one region being wrong either way |
| 1-of-1 | 1 | one fails | nothing, every blip pages |
The third row is the default in a lot of monitoring, and it is the one that generates most false positive alerts.
Why can one region be wrong?
A probe reaches a target over a path it does not own, and every hop on that path can fail without the target noticing. A transit provider drops packets for forty seconds. A DNS resolver near the probe returns a stale answer. A CDN edge in one country is degraded while every other edge is fine.
From inside the target's own network all of this is invisible, because the target is up. Checkmk's write-up on false alerts lists the same family of causes from the operator's side.
We tested this on a small API behind a single-provider CDN for a month. A one-region checker in London reported eleven outages. Two of them were real, and the same two were the only ones a second region in Singapore agreed with. The other nine were path noise, and nine pages for two incidents is the arithmetic that produces alert fatigue.
What does confirmation cost?
Confirmation costs the wait for a second verdict, and that wait is bounded by the check interval. The trade is explicit. A 1-of-1 rule pages fastest and lies most. A 2-of-3 rule pages a little later and lies far less, because two independent paths failing at once is a much rarer event than one.
We prefer the second trade for anything that wakes a person, and the first only for a dashboard nobody is paged from. Google's monitoring chapter asks that every page be urgent, actionable and real, and a page that a second region would have vetoed fails the last test.
Two details keep cross-region quorum confirmation honest. A probe that could not complete its own attempt never counts as a down vote, because the fault was on the probe host rather than the target. The check is re-dispatched instead. And once a target is down, recovery also needs agreement, so one lucky success does not clear an incident that is still happening.
Choosing the three regions
A cross-region quorum is only as independent as its paths. Three probes in one cloud region share the same transit and the same failure, so their agreement proves nothing. Spreading across continents is the simplest way to make the paths independent. It also means a regional outage at the target shows up as one dissenting region rather than a full alarm.
curl -X POST https://uptimeroom.com/api/v1/monitors \
-H "Authorization: Bearer urm_live_..." \
-H "Content-Type: application/json" \
-d '{
"name": "checkout api",
"type": "http",
"target": "https://example.com/api/health",
"intervalSec": 60,
"regions": ["london", "singapore", "sao-paulo"]
}'
The region codes come from the live list on the probe IPs page. That page also publishes each region's egress address, so you can allowlist the checks at your edge.
What quorum cannot fix
Quorum confirmation only removes disagreement between probes. It does nothing about a check that is wrong in the same way from everywhere. A health endpoint that returns 200 while the database behind it is down will pass in all three regions. A WAF rule that blocks every probe will fail in all three.
Those are assertion problems, and they belong to the design of the check rather than to the vote. The outside-in view has limits that no number of regions changes.
It also cannot tell you that a target is down for one geography only. Two regions agreeing the target is up, while a third cannot reach it, is reported as up. That is the correct answer for a global service and the wrong one for a service whose only customers are in the dissenting region. The dissent is worth reading even when it does not page.
Common mistakes
Three regions on one continent. They share transit, so their agreement is one vote wearing three hats. Spread them out.
Reading a one-region failure as an outage. It is a suspicion, and the check-to-incident pipeline exists precisely so that suspicions are confirmed before anyone is paged.
Treating quorum confirmation as the whole defence. Hyperping's own guidance, as of September 2026, calls multi-location verification the most effective single fix for false positives. It is, but the assertion still has to check something real.
A cross-region quorum turns a single probe's opinion into a confirmed fact before it reaches a pager, and the price is one bounded wait. Every plan includes it, starting with the free plan at 10 monitors and a 1-minute interval as of September 2026. There is no reason to let one bad network path page you again.
FAQ
A false positive alert is a page for an outage that did not happen. In uptime monitoring the usual cause is a probe that could not reach a healthy target because of a problem on the network path between them, so the check failed while the service stayed up for everyone else.
Path noise between one probe and the target. A transit hiccup, a stale DNS answer near the probe or a degraded CDN edge can all fail a check from one region while the target is fine. Requiring a second region to agree before the state changes removes most of these, because two independent paths rarely fail at the same moment.
Look at the per-region results for the failed check. A real outage fails from every region at roughly the same time and stays failed. A false positive fails from one region, often for a single check, while the other regions keep passing. The timing waterfall for the failed attempt usually shows where on the path the time went.
Slightly, and by a bounded amount. The alert waits for a second region's verdict, which cannot take longer than the check interval. In exchange the alert is almost always real. For anything that pages a human that trade is worth making, and for a dashboard nobody is woken by, a single region is fine.
Related reading
- Alert Fatigue: How to Cut Your Page Count - Alert fatigue is a volume problem with a number attached. Count pages per responder per week, then use four levers to cut the ones nobody acts on.
- Blackbox Monitoring: What the Outside View Sees - Blackbox monitoring tests a service from outside with no access to its internals, which is how you catch DNS, TLS and routing failures.
- What Is Uptime Monitoring? From Check to Alert - Uptime monitoring checks a service from outside on a schedule and keeps the history. Here is how a failed check becomes an incident, and how fast.