Multi-Region Monitoring

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.

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

devhelm monitors create \
  --name "API Health" \
  --type HTTP \
  --url https://api.example.com/health \
  --frequency 60 \
  --regions us-east,eu-west,ap-south

monitors:
  - name: API Health
    type: HTTP
    config:
      url: https://api.example.com/health
      method: GET
    frequencySeconds: 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:

curl -X PUT https://api.devhelm.io/api/v1/monitors/<monitor-id>/policy \
  -H "Authorization: Bearer $DEVHELM_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "triggerRules": [{
      "type": "consecutive_failures",
      "count": 2,
      "scope": "per_region",
      "severity": "down"
    }],
    "confirmation": {
      "type": "multi_region",
      "minRegionsFailing": 2,
      "maxWaitSeconds": 120
    },
    "recovery": {
      "consecutiveSuccesses": 2,
      "minRegionsPassing": 2,
      "cooldownMinutes": 5
    }
  }'

monitors:
  - name: API Health
    type: HTTP
    config:
      url: https://api.example.com/health
      method: GET
    frequencySeconds: 60
    regions:
      - us-east
      - eu-west
      - ap-south
    incidentPolicy:
      triggerRules:
        - type: consecutive_failures
          count: 2
          scope: per_region
          severity: down
      confirmation:
        type: multi_region
        minRegionsFailing: 2
        maxWaitSeconds: 120
      recovery:
        consecutiveSuccesses: 2
        minRegionsPassing: 2
        cooldownMinutes: 5

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

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:

{
  "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.

Overview

Getting Started

Monitoring Guides

Alerting Guides

Incident Guides

Status Data Guides

Monitoring as Code Guides

Multi-Region Monitoring

Why multi-region matters

Set up multi-region checks

Configure the confirmation policy

Choosing the right configuration

Trigger scope

Region-specific alerting

Next steps

Monitoring regions

Incident policies

Alert routing by tag

​Why multi-region matters

​Set up multi-region checks

​Configure the confirmation policy

​Choosing the right configuration

​Trigger scope

​Region-specific alerting

​Next steps

Monitoring regions

Incident policies

Alert routing by tag

Why multi-region matters

Set up multi-region checks

Configure the confirmation policy

Choosing the right configuration

Trigger scope

Region-specific alerting

Next steps