Prerequisites
Prerequisites
- DevHelm CLI installed or an API token
- At least one monitor — see First HTTP monitor
Why multi-region matters
A single-region check can produce false positives — transient network issues between the probe and your endpoint don’t mean your service is down for users. Running from multiple regions and requiring confirmation from at least two of them dramatically reduces noise.Set up multi-region checks
Configure the confirmation policy
By default, a monitor opens an incident after 2 consecutive failures in a single region. For multi-region confirmation, update the incident policy:- A trigger rule fires when 2 consecutive checks fail in a single region
- The incident only confirms when at least 2 regions report failures within 120 seconds
- Recovery requires at least 2 regions passing
Choosing the right configuration
| Scenario | Regions | minRegionsFailing | maxWaitSeconds |
|---|---|---|---|
| Standard web app | 3 | 2 | 120 |
| Critical API with fast detection | 3-5 | 2 | 60 |
| Global service (low tolerance for false positives) | 5+ | 3 | 180 |
| Single-region service | 1 | 1 | 60 |
Trigger scope
| Scope | Behavior | When to use |
|---|---|---|
per_region | Each region evaluated independently | Most common — detect failures in specific regions |
any_region | Failures aggregated across regions | When you only care about overall availability |
Region-specific alerting
Combine multi-region monitoring with notification policy match rules to route region-specific failures to different teams:Next steps
Monitoring regions
Available probe regions and selection strategies.
Incident policies
Full confirmation and recovery policy reference.
Alert routing by tag
Route alerts based on monitor tags.