Skip to content
Pathwatch Docs

Region health & failover

PathWatch dispatches each scheduled check to a specific cloud region in your monitor’s region list. When a region has trouble — provider-side outage, intermittent network blip, partial DNS failure — the dispatcher reacts so your monitor stays accurate even before you notice.

Three layers of failover

1. Hardened locations — multi-cloud failover

A hardened city is served by two or more independent cloud providers. When the chosen provider’s region in that city goes unhealthy, the dispatcher automatically routes through the other provider. See Regions & locations for the hardened-city list.

This is invisible to you — the monitor keeps reporting from the same city, just via a different backbone. No config change required.

2. Per-failure ramp-down

For each (monitor, region) pair, PathWatch tracks the last few results. When 3 of the last 5 are failures, that region’s weight in the dispatcher’s selection drops by 50 % for that monitor only. Other monitors using the same region continue at full weight — the ramp-down is per-monitor, not provider-wide.

Practical effect:

  • A region that’s flaking for one specific target (DNS issue resolving that target from that region, a peering hiccup, etc.) gets used less for that monitor and more for the alternatives.
  • Other monitors in the same org keep using the region at full weight, so org-wide load doesn’t shift unnecessarily.
  • As soon as the region’s recent results recover, the weight returns to normal.

3. Region health probe

Independently of monitor traffic, PathWatch runs a health probe against every cloud region every few minutes. A region marked degraded by the probe gets its weight halved for all monitors until it recovers. A region marked unavailable is excluded entirely.

You can see each region’s current health at Settings → Regions in the WebUI (admins only). It updates in near-real-time from the probe’s data.

What you see in check results

When a region fails the ramp-down or is fully unhealthy:

  • The monitor’s recent checks page shows the alternate region the dispatcher picked instead. The region you originally chose may stop appearing in the result list for that period.
  • Region-specific alert rules don’t fire spuriously because the dispatcher avoids the bad region in the first place.
  • The monitor’s overall status is computed off the regions that actually ran — skipped results (regions excluded by the dispatcher) are ignored.

Tuning by monitor selection

There’s no per-monitor control on ramp-down — it’s automatic and opinionated. You influence it by which regions you select:

  • Picking only hardened cities — gets the multi-cloud failover layer at no extra cost. Recommended for Free / Starter where the region pool is small.
  • Picking many regions per monitor — gives the dispatcher more alternatives. Five regions tolerates two going bad without losing coverage; one region has nothing to fall back to.
  • Mixing continents — protects against a single backbone issue that’s regionally clustered.

What’s not in the failover

  • Self-hosted runners — they run on your infrastructure, not PathWatch’s. If your runner is down, its checks pause; the dispatcher doesn’t reroute them to a different runner you also own (no cross-runner failover yet).
  • DNS / WHOIS / domain-expiration checks — they call external third-party servers (resolver, registry). Failures of those third parties aren’t a region issue and aren’t ramped down by the dispatcher.
  • Heartbeat monitors — purely inbound; there’s no region to route around.

Tips

  • Use ≥ 3 regions on critical monitors — the dispatcher needs alternatives to fall back to.
  • Hardened locations first — the failover layer is strongest on the cities backed by multiple providers.
  • Don’t manually disable regions — the ramp-down handles transient issues. Disabling a region just to “fix” a noisy alert trades a real signal for a false silence.