Guides / Monitoring
Monitoring
The 3 a.m. page says your site is down. You sit up, open the laptop, hit the URL, and it loads instantly. The dashboard already shows a recovery: down for 90 seconds, back before you'd even unlocked the screen. Your site was fine the entire time. What failed was the monitor's route to it.
This is the false positive problem, and it's baked into how single-location monitoring works. A check isn't an abstract question about your site; it's a real HTTP request travelling a real path: the checker's host, its DNS resolver, its provider's network, the transit links between its datacenter and yours. Every hop on that path can fail on its own, and from the monitor's side of the wire, all of those failures look identical to your site being down.
None of these are hypothetical; they're the routine weather of the internet. A monitor watching from one place inherits all of it as noise, and passes the noise on to you as pages. We learned this on our own infrastructure: a stale DNS cache on one checking node once failed monitors that a manual test from another node passed cleanly, and the fix wasn't touching the target at all; it was fixing the checker. The failure was entirely on the monitoring side, which is exactly the class of problem a second vantage point exists to catch.
The fix is structural: don't let one location's opinion open an incident. When a check fails, re-run it from a different vantage point on a different network before alerting. Two outcomes:
failover.io runs its checking infrastructure in independent locations on separate providers and networks, and a failure has to be confirmed from more than one of them before an incident opens. That single design decision filters out the checker-side DNS blips, the one-network routing hiccups, and the node-under-pressure timeouts, the whole class of "outage" that was never your outage. Combined with the retry threshold (one failed check never pages you anyway; a failure has to persist across consecutive checks), what's left when your phone rings is the real thing.
Monitoring products love the world map with dots on it, and there's a real use for checking from many cities: latency measurement. If you care how fast your site loads from Sydney versus Frankfurt, more probes in more places give you better data.
But for the question "is it down," the map is mostly marketing. Accuracy doesn't come from the count of locations; it comes from requiring independent confirmation before an alert fires. Two vantage points on genuinely separate networks already give you that. Twenty locations that each alert independently just give you twenty sources of false positives, and some products with long location lists still alert on a single failed check from a single probe. When you evaluate a monitor, the question isn't "how many cities," it's "how many independent confirmations before you page me."
A single-location monitor can't tell your outage from its own network problems, so it pages you for both, and every fake page erodes the trust that makes paging useful. The fix is confirmation from more than one independent vantage point before an incident opens, plus a retry threshold so a single blip never rings a phone. failover.io does both by default. When the call comes, it's real.
failover.io confirms every failure from more than one location before it alerts, then escalates until someone acknowledges. Free plan, no credit card.
Start monitoring free →