Where false alarms come from
A monitor says “down” when a request from its location failed. That is a statement about the path between the monitor and your site, not only about your site. Common causes that are not an outage:
- The monitor’s network. A transit provider has a bad few minutes, or the monitoring host has a hiccup.
- DNS resolution at the monitor. The resolver used by one location times out, while others answer.
- A CDN edge or load balancer node in one region that is unhealthy while the others are fine. This is a real problem for visitors near that region, but not a site-wide outage.
- Rate limiting or a web application firewall that blocks the monitor’s addresses after many checks.
- A timeout that is too tight for a slow but working page.
- A planned deploy that restarts the server for a few seconds.
Some of these are real for some visitors. The aim is not to ignore them; it is to tell “the site is down” from “one path is bad” and to treat the two differently.
Three confirmation methods
1. Re-check from the same location
The monitor repeats the failed request a few times, often seconds apart, and calls the site down if every attempt fails. It removes one-packet failures and short blips. It cannot remove a problem that affects the monitor’s location for longer than the retries, such as a routing problem or a blocked address. Some tools offer several retries; the vendor pages describe how many and where.
2. Require several consecutive failed checks
The monitor waits for N failed checks in a row, one per interval, before alerting. With a one-minute interval and N = 3, an alert takes three minutes. It reduces noise at the cost of delay, and it still depends on one location.
3. Confirm from a second region
The monitor re-checks a failure from a different location, and the site is called down only if both agree. Oh Dear’s documentation describes this approach: a failure at the primary location is re-checked from a second, randomly chosen location, and both must report down for an incident, otherwise a warning is logged. Other vendors document their own rules (the alternatives and comparison pages quote them with sources). Beamfar uses two regions: a site is down when both agree, and one region failing is shown as a regional issue with no alert.
The methods can be combined. Confirmation across regions removes path problems; retries remove blips; the right mix depends on the client.
What documented tools do
Vendors publish their rule in different places, and some publish none. This is what their own pages say, read on 2026-10-28; confirm the current text before you rely on it.
| Tool | Rule as documented | Source |
|---|---|---|
| Oh Dear | A failure at the primary location is re-checked from a second, randomly chosen location. Both must report down for the run to fail; if the second succeeds, the run is a warning. | Oh Dear documentation |
| UptimeRobot | Up to three re-checks, about 10 to 20 seconds apart, from a different, randomly chosen data center in the same region. With several regions, the monitor is Down when any single region fails three consecutive checks. | UptimeRobot help |
| Site24x7 | The primary location polls. If it reports down, there are immediate re-checks from 3 locations by default; secondary locations otherwise poll every 30 minutes by default. | Site24x7 support |
| HetrixTools | Checks every minute from up to 12 locations and calls an outage “only when most of them agree”; it does not say how many. | HetrixTools home page |
| Amazon Route 53 health checks | Checkers in many locations vote. An endpoint counts as healthy while more than 18 percent of its checkers report it healthy. AWS says the value was chosen so that an endpoint is not judged unhealthy only because network conditions have isolated it from some checking locations. | Route 53 Developer Guide |
| Better Stack | The page says “No false positives” and does not explain the rule. | Better Stack uptime page |
Two things follow from the table. A re-check inside one region and a check from a second region are different designs: the first removes blips, the second removes problems on one path. And a vote has a threshold that decides what it hides. Route 53’s rule, read the other way, calls an endpoint unhealthy only when 18 percent or fewer of its checkers see it as healthy, so it needs a large majority to fail before it acts. A two-region rule that needs both regions to fail is the same idea at the smallest scale, with the same blind spot: an outage that only some locations see does not raise an alert.
The maths, with made-up numbers
Suppose a single location wrongly sees a failure on a given check with probability p. This is an assumption for illustration, not a measurement of any tool: take p = 0.2% (0.002). With one-minute checks there are 43,200 checks in 30 days.
- Single location, alert on one failure. Expected false alerts: 43,200 × 0.002 = about 86 a month.
- Single location, three consecutive failures. If failures were independent, p³ = 0.000000008, effectively zero. In practice failures are not independent: a bad route lasts minutes, so consecutive failures come together. Do not trust the independence assumption.
- Two regions, both must fail on the same check. If the two locations fail independently, p² = 0.000004, and 43,200 × 0.000004 = about 0.17 a month. Network paths to two regions are far less correlated than consecutive checks from one, which is why this method works better than retries alone.
The numbers show the shape of the argument, not what to expect. The real value of p depends on the tool and the site, and your own data (how many alerts were real) is the only trustworthy source.
The trade-offs
Confirmation is not free. The costs:
- Delay. A confirming check takes time. Compare the time to alert with the client’s needs, not only with the tool’s defaults.
- A partial outage can be hidden. If the site is down for visitors in one region only, a two-region rule shows a regional issue instead of an alert. If your client serves one country, make sure a monitoring region sits near it, and treat regional issues as something to read, not discard.
- Cost. Checking from more regions costs the vendor more, and some vendors charge extra for it. Check the pricing page for how a tool counts locations.
- A false sense of safety. Confirmation does not tell you the site works; it tells you two views agree it does not. A page that returns 200 with an error message is not detected by any of this (see What a 200 response hides).
Designing the alert policy for a client
- Decide what “down” means for this client. Whole site? Checkout? One landing page for a campaign?
- Choose the interval and confirmation together. Faster checks with confirmation are better than slower checks without. See How often should you check a website.
- Say what a regional issue triggers. Nothing? A message in a chat channel? A look by a person within the hour?
- Name who is woken. Out-of-hours alerts need an agreed owner and a retainer that pays for it.
- Keep the evidence. An alert that shows what each region saw, with the status code, timings and DNS answer a click away, saves ten minutes of guesswork and is the best defence if the client questions the alert.
- Review monthly. Count alerts, false alarms and missed events. Adjust.
How Beamfar helps
Beamfar checks each site from every enabled region and calls it down only when two regions agree. Every alert lists what each region saw. If one region fails and the other does not, the site is shown as a regional issue and no alert is sent; if there is no valid measurement, the site shows “data unavailable” and is never counted as up or as zero. The trade-off is the one above: a failure that only one region sees is not an alert, so read the regional issues. Beamfar runs from a fixed set of regions (listed on how it works) and does not let you choose them yet.
Questions
What is a false positive in uptime monitoring?
An alert that says a site is down when it was reachable for visitors. It usually comes from the monitor’s own network, DNS, a firewall blocking the monitor or a timeout that is too tight.
Is checking from two regions better than retrying from one?
They fix different problems. Retries remove short blips, but a routing or blocking problem at the monitor’s location can outlast them. A second region has an independent path, so it is better at telling a site outage from a path problem.
How do UptimeRobot, Oh Dear and Site24x7 confirm that a site is down?
Oh Dear re-checks from a second, randomly chosen location and needs both to agree. UptimeRobot re-checks up to three times from a different data center in the same region and, with several regions, marks a monitor Down when any single region fails three consecutive checks. Site24x7 re-checks from 3 locations by default after the primary location reports down (all read 2026-10-28).
Can two-region confirmation miss a real outage?
It can hide an outage that only one region sees, which is shown as a regional issue instead of an alert. Choose regions near the client’s visitors and read regional issues.
How many failed checks should trigger an alert?
There is no universal number. Combine a fast interval, confirmation from a second location and, if needed, a short delay, and tune from your own record of real and false alerts.
Sources
Read on . Standards and vendor pages change; confirm the current text before you rely on it.
- Oh Dear documentation, uptime and performance monitoring (ohdear.app)
- UptimeRobot help, locations and multi-location (help.uptimerobot.com)
- Site24x7 support, intelligent polling logic during a monitor outage (support.site24x7.com)
- HetrixTools home page (hetrixtools.com)
- Better Stack uptime page (betterstack.com)
- Amazon Route 53 Developer Guide, how Route 53 determines whether a health check is healthy (docs.aws.amazon.com)