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 Virginia, USA us-eastEU West Frankfurt, Germany eu-westAP South Mumbai, India 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,eu-west,ap-south
If you don’t specify regions, the monitor runs from all available regions.
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 minRegionsFailingHow many regions must be failing before an incident is confirmed 1maxWaitSecondsHow 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 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
This configuration requires at least 2 of the 3 regions to report failures before an incident is confirmed. If only us-east fails but eu-west and ap-south 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_regionEach region maintains its own failure count. A region must hit the count independently. any_regionFailures 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 (primary) + eu-west (confirmation)European service eu-west (primary) + us-east (confirmation)Internal/staging monitors Single region is fine
Next steps
Multi-region guide Patterns for reducing false positives.
Incident policies Trigger rules and confirmation in detail.
