/ guides / multi-region-monitoring

Multi-region uptime checks: how regional consensus stops false alerts

How multi-region uptime monitoring decides a site is down: why Fettle needs every fresh region to agree, what a partial failure shows, and the trade-off.

Updated 2026-10-31

Multi-region uptime monitoring checks the same URL from several places in the world and combines the answers into one verdict, so a broken network path between one probe and your server does not page you. Fettle is uptime monitoring for developers that probes from USA, Europe and Asia and marks a monitor DOWN only when every region with a fresh result agrees it is failing, for a configurable number of rounds in a row. A failure seen in some regions but not all shows as DEGRADED: visible on the dashboard, but it opens no incident and sends no alert.

The rest of this guide covers why one probe location lies, how Fettle's rule differs from a majority vote, the trade-off that comes with it, and the settings that shape it.

Why does checking from one location cause false alerts?

A single probe cannot tell your server failing apart from the path to your server failing. A congested transit link, a routing change or a DNS resolver having a bad minute looks exactly like an outage from that one vantage point. Every check fails, the alert fires, and the site is fine for everyone else.

A retry from the same place helps with blips but not with a path that stays broken for ten minutes. A second location does. Your users reach the site over many paths. If the site answers from Europe and times out from Asia, your server is very likely up and something between Asia and your server is not. If it fails from everywhere at once, the problem is almost certainly yours.

That is the whole idea behind multi-region checks. The interesting part is the rule that turns several answers into one status.

Quorum or unanimity: how does Fettle decide a monitor is down?

Fettle uses unanimity, not a majority vote. A monitor goes DOWN only when every region with a fresh result reports a failure (DOWN or ERROR) and that all-failing picture has repeated for the monitor's confirmation threshold of rounds. If even one fresh region still gets an accepted answer, the monitor is not DOWN, and no incident opens.

The common alternative is a quorum: alert when a majority of locations, or some fixed number of them, fail. That rule pages you for an outage that hits most of the world but not all of it. Fettle's rule is stricter on purpose. Every alert it sends means "nothing we probe from can reach this," which is the case where your users are most likely affected too.

The rule, in the order Fettle applies it to each incoming result:

1. Keep the latest result per region. Each monitor stores the most recent check from every region it is configured for. A result older than the one already stored for its region is recorded in the history but changes nothing, so a late DOWN can never overwrite a newer UP.
2. Ignore stale regions. A region's latest result counts only while it is fresh: no more than about two check intervals older than the result being evaluated. Ages are measured between probe times, not against when the result was processed.
3. Count rounds, not results. An all-failing set counts as one round only when every fresh result belongs to the same round of checks. Failures in different regions a minute apart, with a success in between, are not one outage.
4. Decide. All fresh results UP means UP. All fresh results failing, for at least the confirmation threshold of counted rounds, means DOWN. Anything in between leaves DOWN out of reach.

The free multi-region check runs one round of this by hand: it requests your URL from every region at once and shows each region's verdict, status code and response time side by side. A monitor runs the same HTTP check on a schedule and applies the rule above to every round.

What happens when only some regions fail?

The monitor shows DEGRADED once at least one region has failed for as many rounds in a row as the confirmation threshold, while other regions still answer. DEGRADED is a visible status on the dashboard and in the API, with the failing region in the per-region check history. It never opens an incident and never sends an alert.

The confirmation applies here too. With the default threshold of 2, one region timing out once does not change the monitor's status at all. It shows up in the check results and the per-region chart, and that is all. Only a region that keeps failing turns the monitor DEGRADED, and the monitor stays DEGRADED until a full round where every fresh region answers UP. A confirmed failing region that skips one beat does not flash the monitor green.

The monitors list in the API filters by status, so GET /v1/monitors?status=DOWN&status=DEGRADED returns every monitor in a broken state, including the DEGRADED ones nobody was paged about.

What does unanimity miss?

A real regional outage. If your CDN edge in Asia is down while Europe and the USA are fine, users in Asia cannot reach you, and a multi-region Fettle monitor shows DEGRADED rather than paging anyone. That is the price of a rule where every alert means the target is unreachable from everywhere.

There are two ways to cover that case:

• A single-region monitor for the region you care about. Create a second monitor for the same URL with only that region selected. With one region, its failure is unanimous by definition, so that monitor goes DOWN and alerts on its own. The multi-region monitor keeps its quieter rule.
• Watch DEGRADED yourself. Poll the monitors list for DEGRADED from a script or an agent and act on it however you like. Fettle will not turn DEGRADED into a notification for you.

If most of your traffic comes from one part of the world, the first option is worth the extra monitor.

How long does it take to confirm an outage?

Roughly the confirmation threshold times the check interval. The threshold is a per-monitor setting from 1 to 10 counted rounds, 2 by default. At a one-minute interval with the default, an outage that hits every region is confirmed about two minutes after it starts, and the incident is dated from the first failing probe.

A threshold of 1 alerts on the first all-failing round, which is fast and noisier for flaky targets. A higher threshold buys quiet at the cost of minutes. The threshold also sets when a single region counts toward DEGRADED, so the two signals stay consistent with each other.

Stale regions matter here. If one region stops reporting, for example its probe could not run, its last result ages out after about two intervals. From then on the remaining regions decide on their own. A silent region never blocks a DOWN forever, and it never votes with an old answer.

What happens during recovery?

Recovery takes one round where every fresh region answers UP. There is no recovery threshold: the first clean round resolves the incident and sends the recovery notice. Until that round arrives, DOWN is sticky. A partial recovery, with some regions answering again while others still fail, keeps the monitor DOWN.

Stickiness is what stops one outage from becoming two incidents. Without it, a site limping back would go from DOWN to DEGRADED and back to DOWN, and each return to DOWN would open a new incident and send another alert. With it, you get one incident that starts at the first failing probe and ends when the target answers from everywhere again.

How many regions should a monitor use?

Use every region your plan allows unless you have a reason not to. Fettle probes from three regions: USA, Europe and Asia. The free plan checks each monitor from one region, where consensus reduces to that region plus the confirmation threshold. Plus allows up to 2 per monitor, and Pro and up can use all of them.

You choose the regions per monitor, and the pricing page has the region limit for each plan.

Some practical notes:

• A second region already removes most false alerts: a path problem has to hit both at once to page you.
• More regions make the rule stricter, not looser. Every added region is one more place that must fail before you are paged. That is the trade-off above, scaled up.
• SSL, DNS and port-list TCP monitors take a single region. A certificate is the same from every vantage point, and DNS answers that legitimately differ by region (geo-routed DNS) would read as disagreement. Consensus applies to HTTP, ping and single-port TCP monitors.

For what to point a multi-region monitor at, the guide to API health check monitoring covers designing an endpoint worth checking. The broader picture of what uptime monitoring covers is in the uptime monitoring guide, and the rest of the series is on the guides hub.

Questions

Does Fettle alert when only one region fails?

No. A monitor goes DOWN, opens an incident and sends an alert only when every region with a fresh result fails. A failure confirmed in some regions but not all shows as DEGRADED on the dashboard, with no incident and no alert.

How many regions does a Fettle monitor check from?

Fettle probes from USA, Europe and Asia. The free plan checks each monitor from one region; Plus is the first plan that checks from more than one, and you pick which regions each monitor uses.

How do I get alerted about an outage in just one region?

Create a second monitor for the same URL that checks only from that region. With a single region, that region's failure is unanimous by definition, so the second monitor goes DOWN and alerts while the multi-region one shows DEGRADED.

Start monitoring in a minute

The free plan checks up to 20 monitors as often as every 3 minutes from 1 region, and emails you when one breaks. See pricing for the paid intervals, or follow the quickstart to do it from the API.