Choose a regional strategy

What regional checks tell you

Every selected region produces an independent observation of the same target. Comparing those observations helps distinguish service-wide impact from a local route, resolver, carrier, or edge problem.

In everyday language, a region is simply another place checking the same service. If New York cannot reach a website but California and Europe can, Uptime keeps the New York evidence without immediately telling everyone that the entire service is offline.

Regions are evidence sources, not replicas of your customers. Adding more locations improves perspective only when each location represents a meaningful failure domain and the incident policy uses that evidence intentionally.

Ask three questions before selecting regions:

1. Where are the users whose experience matters for this monitor?
2. Which infrastructure or provider failure domains should be independent?
3. How many agreeing regions should be required to declare customer impact?

Start with a service map

Document the service’s traffic path before choosing probes. For a typical SaaS application, that path may include global DNS, a CDN or edge network, a regional load balancer, application compute, and a database. A probe outside the provider can exercise more of that path than a probe beside the application.

Choose regions that create useful contrast. Two locations on the same cloud provider and nearby network can share more failure modes than their city labels imply. For a global service, using US East, US West, and Western Europe is a reasonable initial spread, then adapt it to your actual customers.

Pick a confirmation model

Regional confirmation is the number of failing regions required before an investigation becomes a confirmed incident. It cannot exceed the number of regions assigned to the monitor.

Do not treat these as fixed recipes. A critical authentication service may justify faster confirmation, while a low-priority marketing page may use a more conservative policy.

Combine quorum with streak thresholds

Quorum answers where failures must agree. The failure threshold answers how long each region must continue failing.

{
  "intervalSeconds": 60,
  "failureThreshold": 2,
  "recoveryThreshold": 2,
  "regions": ["us-east", "us-west", "eu-west"],
  "confirmationRegions": 2
}

With this example, a single failed check does not mark a region as failing. A region must fail twice consecutively, and two regions must reach that state before confirmation.

Increasing both values at once compounds detection delay. If you move from a threshold of two to three and from two-region to three-region confirmation, calculate the new worst-case response time and make sure it still fits the service objective.

Patterns by service shape

Global SaaS application

Choose at least three geographically distinct regions near major user populations. Two-of-three confirmation is a strong default because it preserves sensitivity while isolating one local failure. Add more regions when you have customers in additional markets or need evidence across providers.

Region-specific application

Monitor close to the intended users and from one external comparison point. If the application is intentionally reachable only from one geography, use a one-region policy only after confirming that the selected probe reflects the supported access path.

CDN-backed website

Regional results may exercise different edge points while the origin remains shared. Use three or more user-facing regions and inspect response evidence when only one region fails. A local edge issue can be real customer impact even if it should not be announced as a global outage.

External dependency

Select regions that resemble the egress locations of your application. A dependency can be healthy from a generic public probe but unreachable from the network where your workloads run. Consider separate monitors when different workloads have materially different paths.

DNS service

Resolver and propagation behavior can differ geographically. Use multiple regions, assert the expected record type and value when appropriate, and allow intentional propagation time during changes through scheduled maintenance or a temporary policy adjustment.

Interpret disagreement between regions

When one region fails and others pass, treat it as an investigation signal. Check:

• whether the failure is timeout, DNS, TLS, connection, response status, or assertion related;
• whether the same region is failing across unrelated monitors;
• whether the target uses a region-specific CDN or DNS answer;
• whether latency rose before the failure;
• whether maintenance or a deployment overlaps the event.

One failing region may still represent real impact to users in that geography. Regional quorum determines global incident confirmation; it does not make local evidence irrelevant. Record the investigation and create a scoped communication if the local impact is material.

Review the strategy with data

After at least a week, compare average, median, and p95 latency by region on the monitor detail chart. Long-term differences can reveal routing, capacity, or placement issues even when every check passes.

Revisit region selection when:

• customer geography changes;
• infrastructure moves providers or regions;
• one region repeatedly creates isolated failures;
• check volume approaches the plan entitlement;
• a status-page component needs a different customer-impact boundary.

Region changes should preserve historical observations. Removing a region from the active probe fleet or monitor assignment should stop new scheduling without deleting the evidence already used in charts, incidents, or audit history.

Continue with Design an alert policy to connect regional state to delivery behavior.