Uptime monitoring explained: regions, false positives, and what a green badge hides

What a check actually measures

An uptime check is a small, specific claim: a probe sent an HTTP request to your URL and got a response back within a timeout, from wherever that probe happens to run. That is the entire measurement. It does not mean your database is healthy, your background jobs are running, or your checkout flow completes. It means one endpoint answered one request from one location.

Most monitoring tools layer a status decision on top of that raw measurement: operational, degraded, down. The decision logic and the location the probe runs from are both choices the vendor made, usually without telling you what they are. Two problems follow from that, in opposite directions: checks that flip to “down” on noise (false positives), and checks that stay green while real customers are broken (false negatives, which is what the single-location blind spot causes). This guide covers both, and what actually fixes each.

False positives: why a healthy service still flips to “down”

A false positive is an alert or status change with no real user-facing problem behind it. The usual cause isn't a mysterious flake, it's one of these:

• A single failed probe treated as a real outage. Networks drop packets. A probe server has a bad second. Your host has a brief GC pause. Any monitor that flips state on the first failed check will alert on noise constantly, because transient failures are the normal background rate of running anything on the internet, not an anomaly.
• The probe location, not your service, having a bad path. If the monitoring vendor's single check location has a routing problem to your host, your status page reports you as down to the entire world, even though every real visitor is reaching you fine. The “outage” is between the vendor and their own probe, not between your customers and you.
• Checks that don't know about planned maintenance. A deploy that intentionally takes an endpoint down for 90 seconds looks identical to an unplanned outage to a monitor with no concept of a maintenance window, so it alerts and opens an incident for something you already knew about and told no one was a problem.

The fix for the first one is hysteresis: require more than one consecutive failure before treating a check as really down, and require recovery to be confirmed the same way. realuptime status requires two consecutive failed probes from a region before that region's state flips to down, and a single successful probe to flip it back to operational. A single dropped connection updates the raw history but does not, by itself, open an incident or fire an alert.

The fix for the second is regional independence, covered below: if only one of several check locations disagrees with the rest, that is evidence the problem is closer to the checker than to you.

The fix for the third is a maintenance window the monitor actually respects. A scheduled window suppresses the outbound alert for a check tied to it, while the underlying check history and public incident record stay accurate underneath, so the page never lies by staying artificially green, it just doesn't page anyone for something already announced.

False negatives: what a single-region check misses

The opposite failure is more dangerous because nobody gets paged. A check running from one cloud region, usually wherever the monitoring vendor's own infrastructure happens to live, only proves reachability from that one place. A regional outage, a bad deploy that only breaks your Asia-Pacific edge, a CDN node failing in Europe, a database replica falling over in one availability zone, can leave every customer in that region seeing errors while the single distant check keeps passing and the badge stays green.

This is common enough that a small industry exists specifically to catch it: third-party monitoring firms who watch other companies' infrastructure independently because vendors' own status pages routinely miss regional and partial outages. Read the full mechanics in why your status page shows all green during a real outage.

What checking from multiple regions actually buys you

Checking from more than one place turns a single ambiguous data point into a comparison. If four regions check the same URL and three report healthy while one reports down, you now have real evidence about where the problem is:

• One region down, others healthy: a genuine regional or network-path issue worth investigating, and worth telling the customers actually affected instead of everyone.
• All regions down at once: a real, global outage; the failure isn't about geography, so treat it as a full incident immediately.
• One region flickers alone, briefly, then recovers: more likely a routing blip between that specific checker and your host than a customer-facing problem, especially if it doesn't clear the two-consecutive-failure threshold.

The regions themselves need to be real and independent, not one location with the results copied four times, and the per-region result needs to be shown, not collapsed back into a single badge before it reaches the page. A tool that checks from four regions internally but still only publishes one operational/degraded/down state has quietly thrown away the one piece of information that made checking from four places worth doing.

What this means for your alerting, not just your status page

The same reasoning applies to who gets paged, not only to what the public page shows. A single failed probe from one region is not an incident; page no one for it. Two consecutive failures from one region, with the others still healthy, is worth a Slack message to your team and, if the service is customer-facing, worth updating subscribers on the specific region affected. Every region failing at once is worth waking someone up. Calibrating alert severity to actual evidence, instead of firing the same alert on every red data point, is most of what separates monitoring people trust from monitoring people mute.