- Per-region status, timing and resolved IP
- Confirmation from all two regions before an incident opens
- Regional degradation shown on status pages when you enable it
- Pick the regions that match your audience
Other features
What happens in the first minute after a failure
A check that fails in one place proves very little. The server could be down, but so could a peering link, a regional CDN edge or the checker’s own network. So when a region sees a failure, the monitor goes into a suspect state for that region and the other regions are asked to run the same check right away. Today the live regions are Amsterdam and London, which means all two regions have to agree before an incident opens. The default confirmation window is 60 seconds, and recovery is confirmed the same way, so a site that bounces up and down produces one incident with several state changes inside it rather than a string of separate pages.
This is the single biggest source of calm in an on-call rota. Most one-off failures are transient: a dropped TCP connection, a DNS resolver having a bad second, a 502 while a container restarts. Confirmation filters those out without making you raise the check interval to hide them.
2 regions today, and what the plans allow
We only count regions that actually run a checker process. Copy and billing never promise more regions than are live, and the plan limits decide how many of them a monitor can use. Free uses 1 of them. Starter, Pro and Agency use up to 2. When the live list changes, the numbers on this page change with it.
Fewer regions is not a disaster, it just changes the odds. With only two regions a failure can only be double-checked once, so a very short network blip that happens to hit both is more likely to get through. That is one reason the free plan is for your own side project and the paid plans are for sites you have promised to keep up.
Reading the per-region view
Open a monitor and you get the latest result per region: status, total time and the IP the hostname resolved to. The pattern tells you where to look.
- One region red, the others green: a routing, geo-blocking or regional CDN problem. Check whether the failing region resolved a different IP from the rest.
- Every region red with the same error: the origin or the application. A 502 or 503 from all of them points at the server, a TLS handshake failure from all of them points at the certificate.
- Every region slow, one very slow: look at the timing breakdown for that region. A long connect time is network, a long first-byte time is the application.
- A blocked severity instead of down: the site answered, but with a bot challenge or a WAF block page. The fix is allow-listing, not hosting. The published checker IPs exist for exactly this.
Choosing regions for a site that serves one country
Confirmation needs several independent vantage points to be meaningful, so even a purely local business should keep all live regions enabled. What you can tune is the region you read the latency numbers from. A Tallinn dentist should look at Amsterdam and Frankfurt timings and treat New York as a sanity check, because 100 ms of Atlantic crossing says nothing about what a local patient experiences.
Response-time alerts can be scoped to one region for the same reason (Pro and above), which is covered on the response time page. Check frequency is separate: Free runs every 5 min, Starter every 1 min, Pro and Agency down to 30 s.
What it does not do
Multi-location checking tells you whether the site is reachable from our network locations. It cannot see your visitor’s own ISP, a corporate proxy or a country-level block, so a single customer who cannot load the site while all regions are green is still possible. It also does not run a real browser by default; for a login flow or a checkout you want a keyword or API check on the right URL.
Single-region monitors exist and skip confirmation, which means they alert on the first failure. The interface labels them clearly. Use them for internal endpoints that only one location can reach, not for public sites.
If you are weighing this against other tools, the practical difference is how many locations must agree, and whether that number is honest. Some products advertise a long region list on every plan; check their pricing page for how many are included at your tier. For the longer story of why we confirm at all, see how we confirm downtime from three regions.
Questions
Can I pick which regions run my checks?
You choose the regions per monitor from the ones that are live and allowed by your plan. We recommend leaving confirmation on for any public site, since it needs several regions to work.
Why was I not alerted when my site was unreachable for a few seconds?
The other regions answered successfully, so the failure was treated as local to one path and no incident opened. The failed result is still stored in the monitor history, so you can see it afterwards.
Do I get more regions when you add new ones?
Paid plans use every live region up to their allowance, so new locations apply automatically. Free stays at 1 region.
Do the checker IPs change?
They are published at /checker-ips and as JSON, and the list is what to use for firewall and WAF allow-lists. Re-fetch it from the JSON endpoint instead of copying addresses into a rule once and forgetting.
Start monitoring in two minutes
30 monitors free, forever. No credit card. Moving from UptimeRobot? Import your monitors in one click with a read-only API key.