Multi-region setup

DevFlow runs synthetic checks from 14 edge locations. You pick a subset; we run the same check from each.

the 14 edges

us-east-1 (Virginia), us-east-2 (Ohio), us-west-2 (Oregon), ca-central-1 (Montréal), sa-east-1 (São Paulo), eu-west-1 (Dublin), eu-west-2 (London), eu-central-1 (Frankfurt), eu-north-1 (Stockholm), ap-southeast-1 (Singapore), ap-southeast-2 (Sydney), ap-northeast-1 (Tokyo), ap-south-1 (Mumbai), af-south-1 (Cape Town).

why multiple regions

A check that runs from one region will fire alerts when that region can't reach you, even if the rest of the world is fine. Multi-region with quorum stops that.

quorum

The default mode is fail-quorum: the monitor counts as failed only when strictly more than half of the configured regions agree it failed. With 3 regions selected, that's 2 of 3. With 5, it's 3 of 5.

regions: [us-east-1, eu-west-1, ap-southeast-1]
quorum:
  mode: fail-quorum  # default

Other modes:

• any — any single region failing trips the monitor. Useful for region-locked APIs you only serve from one place.
• all — every region must fail. Conservative; reduces false positives but can mask real degradation.

picking your regions

Three regions across three continents is the sweet spot for a global API: one of [us-east-1, us-west-2], one of [eu-west-1, eu-central-1], one of [ap-southeast-1, ap-northeast-1]. Adding more increases cost without much signal.

edge isolation

Each edge runs an independent prober. We do not share TCP connection pools across regions, so a single region's network blip does not poison the others. The probe binary is the same across regions; we deploy weekly.

For more on alert handling when the monitor fails, see alert-routing and notification-throttling.