Skip to main content
By the end of this guide, you’ll have monitors running from multiple probe regions with a confirmation policy that requires failures from more than one region before opening an incident.

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

devhelm monitors create \
  --name "API Health" \
  --type HTTP \
  --url https://api.example.com/health \
  --frequency 60 \
  --regions us-east,eu-west,ap-south
Each check cycle, DevHelm runs the monitor from all configured regions independently.

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:
devhelm monitors update-policy <monitor-id> \
  --trigger-type consecutive_failures \
  --trigger-count 2 \
  --trigger-scope per_region \
  --trigger-severity down \
  --confirmation-min-regions 2 \
  --confirmation-max-wait 120
This means:
  • 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

ScenarioRegionsminRegionsFailingmaxWaitSeconds
Standard web app32120
Critical API with fast detection3-5260
Global service (low tolerance for false positives)5+3180
Single-region service1160

Trigger scope

ScopeBehaviorWhen to use
per_regionEach region evaluated independentlyMost common — detect failures in specific regions
any_regionFailures aggregated across regionsWhen 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:
{
  "name": "APAC failures to APAC team",
  "matchRules": [
    { "type": "region_in", "regions": ["ap-south", "ap-southeast"] }
  ],
  "escalation": {
    "steps": [{
      "delayMinutes": 0,
      "channelIds": ["<apac-slack-channel-id>"]
    }]
  }
}

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.