Probe Regions

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`

Additional regions are added based on demand. Run devhelm monitors create --help to see the latest available regions.

Configuring regions

Specify one or more regions when creating a monitor:

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

monitors:
  - name: API Health
    type: HTTP
    config:
      url: https://api.example.com/health
      method: GET
    regions:
      - us-east
      - us-west
      - eu-west
      - ap-south

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)`

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

Getting Started

Monitoring as Code

Monitoring

Incidents

Alerting

Status Data

Platform

Common Patterns

Available regions

Configuring regions

Multi-region strategy

Why use multiple regions

How confirmation works

Per-region vs any-region scope

Region selection guidelines

Next steps

Multi-region guide

Incident policies

​Available regions

​Configuring regions

​Multi-region strategy

​Why use multiple regions

​How confirmation works

​Per-region vs any-region scope

​Region selection guidelines

​Next steps

Multi-region guide

Incident policies

Available regions

Configuring regions

Multi-region strategy

Why use multiple regions

How confirmation works

Per-region vs any-region scope

Region selection guidelines

Next steps