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