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

# Probe Regions

> Available DevHelm probe regions and multi-region monitoring strategies for reducing false positives

DevHelm runs monitor checks from distributed probe regions. Multi-region checks reduce false positives by requiring failures from multiple locations before opening incidents.

## Available regions

| Region | Location | Code |
| - | - | - |
| US East | New York, USA | `us-east` |
| US West | San Francisco, USA | `us-west` |
| EU West | London, UK | `eu-west` |
| AP South | Singapore | `ap-south` |

<Note>
  Additional regions are added based on demand. Run `devhelm monitors create --help` to see the latest available regions.
</Note>

## Configuring regions

Specify one or more regions when creating a monitor:

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

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

If you don't specify regions, the monitor runs from `us-east` (or your organization's default region set, if one is configured).

## Multi-region strategy

### Why use multiple regions

A single-region monitor can trigger false incidents when:

* The probe region has a temporary network issue
* A cloud provider has a localized outage
* Routing between the probe region and your service degrades

Multi-region monitoring eliminates these false positives by requiring confirmation from multiple locations before opening an incident.

### How confirmation works

The incident policy's `confirmation` section controls multi-region behavior:

| Field | Description | Default |
| - | - | - |
| `minRegionsFailing` | How many regions must be failing before an incident is confirmed | `1` |
| `maxWaitSeconds` | How long to wait after the first region fails for other regions to confirm | `max(60, frequency × 2)` |

```yaml theme={null}
monitors:
  - name: API Health
    type: HTTP
    config:
      url: https://api.example.com/health
      method: GET
    regions: [us-east, us-west, 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 configuration requires at least 2 of the 4 regions to report failures before an incident is confirmed. If only `us-east` fails but the other regions are healthy, no incident opens.

### Per-region vs any-region scope

Trigger rules have a `scope` that controls how failures are counted:

| Scope | Behavior |
| - | - |
| `per_region` | Each region maintains its own failure count. A region must hit the count independently. |
| `any_region` | Failures from any region count toward the same counter. |

For most setups, use `per_region` with `minRegionsFailing: 2` — this ensures each confirming region has independently detected the failure.

## Region selection guidelines

| Scenario | Recommended regions |
| - | - |
| Global SaaS application | All available regions |
| US-focused service | `us-east` + `us-west` (primary) + `eu-west` (confirmation) |
| European service | `eu-west` (primary) + `us-east` (confirmation) |
| Asia-Pacific service | `ap-south` (primary) + `us-west` or `eu-west` (confirmation) |
| Internal/staging monitors | Single region is fine |

## Next steps

<CardGroup cols={2}>
  <Card title="Multi-region guide" icon="earth-americas" href="/guides/multi-region-monitoring">
    Patterns for reducing false positives.
  </Card>

  <Card title="Incident policies" icon="triangle-exclamation" href="/incidents/policies">
    Trigger rules and confirmation in detail.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.