Regions & locations
This page lists every location a PathWatch check can run from, what plans see what cities, and how the redundancy model works under the hood. The numbers come from the API at build time, so they stay in sync with the live deployment without anyone editing markdown.
Locations vs. regions
PathWatch separates the user-facing concept of a location (a city — “London”, “Tokyo”, “São Paulo”) from the underlying cloud regions that serve it.
- You pick locations when configuring a monitor. The picker shows city names, never cloud-provider names.
- The dispatcher routes each scheduled check to one of the cloud regions backing that location, using weighted random selection with health awareness.
When a single location is backed by two or more independent cloud providers (e.g. one AWS region and one GCP region both in Frankfurt), it’s marked hardened. Hardened locations survive an outage of one entire cloud provider — the dispatcher fails over between providers automatically.
When a location is backed by only one provider, it’s still highly available within that provider’s infrastructure (per-AZ replication, auto-recovery), but a full provider-wide outage in that region would take it offline. The deployment footprint trades coverage breadth against per-city redundancy depending on which locations actually get monitored most.
Tier system
Every location is tagged with a tier from 1 (most widely available) to 5 (most expensive, niche, or limited-availability). Plans gate access to higher tiers.
| Tier | Label | Cost driver | Plans that include it |
|---|---|---|---|
| 1 | Essential | Cheapest hubs, baseline global coverage | Free, Starter, Pro, Business |
| 2 | Standard | Additional cheap regions | Starter, Pro, Business |
| 3 | Extended | International expansion, some premium pricing | Pro, Business |
| 4 | Premium | Expensive provider regions (e.g. tier-2 pricing zones) | Pro, Business |
| 5 | Global | Niche regions, limited availability, or contractual access | Business |
The per-plan region count cap is also enforced — a Pro plan with access to tier 4 still caps at 39 total picks per monitor (see Limits & quotas).
Backups & redundancy
Each row in the table below carries two redundancy figures:
- Cloud regions — how many distinct cloud-provider regions serve this city. Two regions in the same city give you in-city failover if one provider region degrades.
- Backups —
cloud_regions − 1. Reads cleanly as “0 backups” for a single-provider city, “1 backup” for a city served by two independent providers, and so on.
A city with 1+ backups is multi-cloud — it survives a full outage of one cloud provider. Single-cloud cities can still survive provider-internal incidents (zonal outages, single-AZ degradations) via the provider’s own redundancy.
Live region list
3 cities · 6 total cloud regions · 3 hardened (multi-cloud) locations.
North America — 1 city
| City | Country | Tier | Cloud regions | Backups | Hardened |
|---|---|---|---|---|---|
| Ashburn | United States | 1 · Essential | 2 | 1 | Yes |
Europe — 1 city
| City | Country | Tier | Cloud regions | Backups | Hardened |
|---|---|---|---|---|---|
| London | United Kingdom | 1 · Essential | 2 | 1 | Yes |
Asia — 1 city
| City | Country | Tier | Cloud regions | Backups | Hardened |
|---|---|---|---|---|---|
| Tokyo | Japan | 2 · Standard | 2 | 1 | Yes |
The list refreshes daily — if you spot a city that’s not here yet, it isn’t deployed yet. Cities marked Hardened: Yes are the ones backed by two or more cloud providers; choosing those first gives your monitors the strongest failover guarantees.
Picking locations for a monitor
Some practical guidance:
- At least two locations per monitor — confirmation logic needs at least two regions to distinguish a real outage from one flaky checker. Three is comfortable; five+ adds rapidly diminishing returns.
- Match your customer geography — a SaaS with 70 % US customers should weight North America heavily; the cheap rest of the world is for completeness, not for primary signal.
- Mix continents for global SaaS — at least one North America, one Europe, one Asia gives you a believable global view from three independent failure domains.
- Use hardened cities when on Free / Starter — your tier-1 pool is small (6 / 16 cities). Picking the hardened subset of those gives the best uptime story you can build at that plan.
- Use self-hosted runners for internal targets — the cloud region list is for monitoring public endpoints. For VPC-only or on-prem services, see self-hosted runners in TechDocs.
What’s not in the list
- Self-hosted runners — these are operator-managed and don’t show up in the public list. They live in your monitoring config as a separate region pool labelled with whatever provider name you chose at enrolment time.
- Internal cloud probes — region health probes and warming pings the dispatcher uses internally aren’t user-facing regions and aren’t listed.
- Coming-soon regions — only regions currently passing health checks appear. A region in deployment but not yet healthy is invisible until it goes live.