Per-Monitor Regions

Last updated: 2026-05-12

Your default monitor locations are account-wide. They apply to every monitor unless you override a specific monitor in Add Monitor or Edit Monitor using Per-Monitor Regions.

Use per-monitor regions when different services need different geographic coverage. For example, your public website may need checks from several continents, while an internal EU-only API may only need European confirmation regions.

If you have not set your account-wide defaults yet, start with Choosing Monitor Locations.

Account Defaults vs Per-Monitor Overrides

StatusPage supports two layers of region selection:

If a monitor has a custom per-monitor region selection, that monitor no longer follows your account defaults. Other monitors continue using the default set unless you override them too.

This gives you a simple model:

• use account defaults for the common case
• use per-monitor regions only when a monitor needs different geography

Where to Configure Per-Monitor Regions

You can set per-monitor regions in two places:

1. Open Add Monitor when creating a new check
2. Or open Edit Monitor for an existing monitor
3. Find the Per-Monitor Regions section
4. Check the regions you want that monitor to use
5. Optionally choose a Primary region for that monitor
6. Save the monitor

If you leave the monitor-level primary region blank, the monitor uses your default primary region.

For account-wide defaults, see Choosing Monitor Locations. For primary-region behavior, see Setting Your Primary Monitoring Region.

What the Monitor-Level Primary Region Does

Per-monitor primary region selection works the same way as the account-wide primary region, but only for that one monitor.

• the primary region runs the scheduled check every interval
• the other selected regions act as secondary confirmation regions
• if the primary sees a failure, secondaries run confirmation checks
• enough secondaries confirming the failure produces a real outage instead of a regional false positive

This is useful when one monitor serves a different audience than the rest of your account.

Examples:

• your main app is US-focused, so its primary should be in North America
• your checkout service is Europe-focused, so its primary should be in Europe
• your globally used API may still use a global default while a smaller regional service uses a narrower monitor-specific set

For more on quorum confirmation, see Monitoring Accuracy & Detection Tracking.

When You Should Override the Defaults

Per-monitor overrides make sense when a monitor differs from the rest of your account in a meaningful way.

Common reasons:

• the service is used mostly in one region
• the monitor checks infrastructure deployed in a specific geography
• you want tighter confirmation near a high-value customer segment
• the default region set is too broad or too narrow for one specific service

If most of your monitors need the same change, update the account defaults instead of creating many overrides.

Plan Limits and Availability

Per-monitor region settings follow the same location limits as the rest of your monitoring plan.

Important:

• the monitor-level selection still counts against your plan’s location allowance
• free plans stay locked to the platform default primary region
• if a plan does not include per-monitor overrides, the monitor follows your account defaults

For the full plan matrix, see Plan Limits & Quotas.

Example Setups

Example 1: Global marketing site, regional API

Your website serves users in North America and Europe, but an internal API is only used by your EU operations team.

• keep broad account defaults for the website monitor
• override the API monitor to use European regions only

Example 2: New Southern Europe traffic

You added customers in Italy, Greece, and the Balkans and want faster confirmation for that audience.

• keep your normal account defaults for most monitors
• override the customer-facing monitor and include Milan in its region set
• if Southern Europe is the most important audience, set Milan as that monitor’s primary region

Example 3: High-noise monitor

One monitor often trips from a region that is not important to your customers.

• narrow that monitor’s regions to the places that reflect real user impact
• keep broader coverage on your other monitors

This often reduces alert noise without weakening coverage for services that need broader validation.

How It Affects Accuracy

Per-monitor regions change where the monitor checks from. They do not change the basic quorum logic.

The result is usually better alignment between:

• where your users are
• where the monitor checks from
• what counts as a real customer-visible outage

That helps with:

• faster detection in the right geography
• fewer false positives from irrelevant regions
• cleaner incident evidence when an outage is regional instead of global

If you want the broader operating model, read Choosing Monitor Locations and How to Reduce Monitoring False Positives.

FAQ

Does changing per-monitor regions affect other monitors?

No. A per-monitor override only affects the specific monitor you edit.

Can I leave the monitor-specific primary region empty?

Yes. If you do not choose a monitor-level primary region, the monitor uses your default primary region.

Should every monitor have its own custom region set?

Usually no. Use account defaults for the common case. Add overrides only when a monitor has different geography, user distribution, or alerting needs.

Is this mainly for reducing false positives?

That is one strong use case, but it is also useful for making latency and outage confirmation reflect the regions that matter for each service.

What’s Next?

• Choosing Monitor Locations — manage your account-wide default region set
• Setting Your Primary Monitoring Region — choose the default primary region for scheduled checks
• Monitoring Accuracy & Detection Tracking — understand how quorum confirmation works
• Set up your first monitor — create a new check and decide where it should run from