A false alarm and a real outage, ten minutes apart

Everyone selling multi-region monitoring says it cuts false alerts. Here is what that actually looks like in a database, using rows from our own monitors.

Published 2026-09-09 · Pulsecima Pulse engineering

The claim on our pricing page is narrow and testable: we check your URL from three independent regions, and we only confirm an incident when at least two of them agree. One region seeing a failure is not an incident. It is one opinion.

That is easy to say. What follows is what it looked like on a specific morning.

04:32 — one region said down. Two disagreed.

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. The majority did not agree that anything was wrong, 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 agreed. That one we sent.

Ten minutes later, the same monitor failed again. This time the disagreement was gone:

-- 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 quorum 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 last 30 days, 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; we are showing you what the mechanism does when it fires, 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

Quorum 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 all three regions agree, 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.

Related: how quorum alerting works · cron job monitoring · FAQ