> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devhelm.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Multi-Region Monitoring

> Reduce false positives with DevHelm multi-region monitoring and confirmation policies

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.

<Accordion title="Prerequisites">
  * DevHelm CLI installed or an API token
  * At least one monitor — see [First HTTP monitor](/guides/first-http-monitor)
</Accordion>

## 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

<CodeGroup>
  ```bash CLI theme={null}
  devhelm monitors create \
    --name "API Health" \
    --type HTTP \
    --url https://api.example.com/health \
    --frequency 60 \
    --regions us-east,eu-west,ap-south
  ```

  ```yaml devhelm.yml theme={null}
  monitors:
    - name: API Health
      type: HTTP
      config:
        url: https://api.example.com/health
        method: GET
      frequencySeconds: 60
      regions:
        - us-east
        - eu-west
        - ap-south
  ```
</CodeGroup>

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:

<CodeGroup>
  ```bash API theme={null}
  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
      }
    }'
  ```

  ```yaml devhelm.yml theme={null}
  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
  ```
</CodeGroup>

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](/alerting/notification-policies#match-rules) to route region-specific failures to different teams:

```json theme={null}
{
  "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

<CardGroup cols={2}>
  <Card title="Monitoring regions" icon="globe" href="/monitoring/regions">
    Available probe regions and selection strategies.
  </Card>

  <Card title="Incident policies" icon="sliders" href="/incidents/policies">
    Full confirmation and recovery policy reference.
  </Card>

  <Card title="Alert routing by tag" icon="tags" href="/guides/alert-routing-by-tag">
    Route alerts based on monitor tags.
  </Card>
</CardGroup>