One region failed alone. Ten minutes later, three did.

Multi-region monitoring is easy to describe and harder to see. Here is what it looked like in a database, using rows from our own monitors.

Published 2026-09-09 · Pulsecima Pulse engineering

The rule on our pricing page is narrow and testable: we check your URL from three independent regions, and at least two fresh regions must report a failure before we confirm an incident. One region seeing a failure is not, by itself, an incident. It is one observation.

That is easy to say. What follows is what the earlier model recorded on a specific morning.

04:32 — one region reported a failure. Two did not.

A monitor watching news.ycombinator.com failed its check in one region. Under single-region monitoring, that is a page. Here it became a row in a different table:

-- quorum_suppressions
2026-08-26 04:32:15   fresh_region_count = 3   disagreeing_region_count = 2

Three regions had a fresh result. Two of them still saw the site as healthy. A failure seen by only one region was not confirmed, so no alert was sent and the event was recorded as a suppression instead. Nobody was woken up. Nobody had to decide, at 4:32 in the morning, whether a single timeout was worth investigating.

04:42 — all three reported it. That one we sent.

Ten minutes later, the same monitor failed again. This time every fresh region reported the failure:

-- quorum_incidents
2026-08-26 04:42:15   fresh_region_count = 3   bad_region_count = 3
                      resolved 04:52:06   (10 minutes)

All three regions, on three continents, reported the same failure. That is not a network hiccup near one checker, and we alerted on it. Ten minutes later it recovered and the incident closed on its own.

Same monitor. Same morning. Ten minutes apart. One was noise and one was real, and the difference between them is not something a single checker can see — from one vantage point both events look identical.

Why one region cannot tell these apart

A single-region checker observing 04:32 sees a request that timed out. Observing 04:42 it sees a request that timed out. There is no field in the response that says "this one was your own network." The only way to separate them is to ask somewhere else at the same moment.

This is why we treat one region's failure as a question rather than an answer. It also means the value of cross-region confirmation is invisible when it works — a suppressed alert produces silence, and silence is hard to appreciate. That is the reason we record suppressions as first-class rows and show the count on your dashboard: so the alerts you didn't get are something you can actually look at.

The numbers, with their limits stated

Over the 30 days before 2026-09-09, across our own monitors:

Two honest caveats, because numbers this small are easy to oversell.

The sample is tiny. Two suppressions and one confirmed incident is an anecdote, not a statistic. We are not claiming a false-positive reduction rate, and we can't prove that a suppressed event was not a real problem; we are showing you what the mechanism did when it fired, with the actual rows.

The regions have different histories. The three counts above are not directly comparable because the regions did not all record for the same span — we rebuilt our worker deployment in late August, and ap-southeast-1 and eu-west-1 have been reporting continuously only since then. The August 26 events above are from after that work was complete, with all three regions confirmed live.

Where this does not help

Cross-region confirmation reduces one specific kind of noise: a failure visible from one vantage point and not the others. It does nothing about a genuinely flaky endpoint that is equally flaky everywhere, and it does not make a real outage quieter — when at least two fresh regions report the failure, you get paged, which is the point.

It also cannot help if fewer than two regions are actually reporting. That is a real failure mode, and we now alert ourselves on it and show live region coverage in our operator console rather than assuming three regions are always up. In that case Pulsecima can't confirm an incident at all.

One more limit, stated plainly: a result only counts while it is fresh (within about twice your check interval, and at least 5 minutes). A failure from one region never opens an incident on its own — not after a restart, and not from any particular region.

Related: how cross-region confirmation works · cron job monitoring · FAQ