Multi-region checks
Run a single monitor from multiple geographic locations to spot regional failures and reduce false positives.
A single-region monitor only sees the world from one network vantage point. If
that region's transit provider has a brownout, your monitor reports down even
when your service is healthy elsewhere. Multi-region checks fix that by running
the same check from several locations every interval, so you can tell regional
network blip apart from real outage.
How it works
When you assign more than one region to a monitor, every region runs the check independently on its own schedule. Each region's result is written separately to the time-series store, so you get one row per region per interval — not a single aggregated value.
There is no quorum or majority vote. Each result updates the monitor's "last status" as it arrives, and the dashboard shows you the per-region timeline so you can see which locations succeeded and which failed.
What multi-region buys you in practice:
- Visibility. The per-region map and timeline show exactly where a failure is happening — useful for pinpointing CDN edge issues, regional ISP outages, or geo-DNS misconfigurations.
- Latency from multiple geographies. Track real user-perceived latency from the regions where your customers actually live.
- Smoother auto-incident behavior. StatusOwl auto-opens an incident only
after three consecutive
downresults for a monitor (across all regions, in arrival order). With multiple regions checking, a single misbehaving region is unlikely to produce three down results in a row before another region'supresult resets the counter — so transient single-region blips don't page you.
Multi-region is not a vote
Three regions all reporting up while a fourth reports down will still flip
the monitor's last-status indicator to down when that fourth result lands —
because every result counts. The auto-incident threshold (3 consecutive
failures) is what filters out single-region noise, not a majority gate. If you
want stricter regional consensus before alerting, use a custom webhook
integration to apply your own logic.
Available regions
StatusOwl currently runs monitoring nodes in:
| Code | Location | Continent |
|---|---|---|
nyj | New York / Newark | NA |
lax | Los Angeles | NA |
dal | Dallas | NA |
tor | Toronto | NA |
lon | London | EU |
fra | Frankfurt | EU |
ams | Amsterdam | EU |
sin | Singapore | APAC |
mum | Mumbai | APAC |
syd | Sydney | APAC |
sao | São Paulo | SA |
The active region list is dynamic and may change. The current set is shown in the region picker when you create or edit a monitor.
Plan gating
The number of regions you can assign to a single monitor is controlled by your
plan's max_regions_per_monitor value:
- Free — 1 region per monitor (typically
global). - Paid plans — more regions per monitor; see the pricing page for the current allotment per tier.
When you exceed your plan's limit on create or update, the API returns a 403
with Region limit exceeded. Your plan allows N region(s) per monitor. Please upgrade to add more.
Choosing regions
A few practical guidelines:
- Pick regions where your users are. Three monitors all checking from US East tells you nothing about your European customers' experience.
- Cover the major continents you serve. A common starting set is one NA region, one EU region, and one APAC region.
- More isn't always better. Doubling regions doubles your check volume. For an HTTP endpoint at 60-second intervals across 6 regions, that's 8,640 requests per day per monitor — make sure your origin can handle it (or use a longer interval).
- Avoid regions that get blocked. Some services geofence inbound traffic.
If a region is permanently blocked by your service's WAF, it'll report
downforever and you'll mute it — don't use it in the first place.
Per-region latency
The monitor detail page renders latency separately for each assigned region, so you can spot regional regressions independently — for example, if Singapore suddenly jumps from 80ms to 400ms while everywhere else is unchanged, you've likely got an APAC routing issue at your CDN, not a code regression.
Maintenance and tuning
- A single region keeps failing while others are fine. Either the network path between that region and your origin is degraded (a real signal worth investigating), or your origin is geofencing that region. Check your WAF / firewall rules first.
- All regions fail simultaneously. That's almost always a real outage — your service, your DNS, or your provider's backbone.
- Want to remove a region temporarily? Edit the monitor and uncheck the region. Removed regions stop checking immediately; their historical data stays.
Limitations
- StatusOwl does not currently support failure-correlation rules (e.g., "alert only if 2 of 3 regions fail"). Auto-incidents use a simple consecutive- failure threshold across all results.
- Region availability changes over time as nodes are added or retired. The region list shown in the dashboard is authoritative.