What does an uptime check measure?
An uptime check measures one thing: whether a probe got a response from your URL within a timeout. The probe sends an HTTP request from wherever it happens to run. “Response” usually means a status code in the success range defined by RFC 9110, and nothing more.
A passing check 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. Google's SRE book calls this black-box monitoring: it sees what a user would see, and it sees only that.
Most monitoring tools layer a status decision on top of the raw measurement: operational, degraded, down. The decision logic and the probe location are both choices the vendor made, usually without telling you what they are. Two problems follow, in opposite directions. Checks flip to “down” on noise (false positives), and checks stay green while real customers are broken (false negatives, which the single-location blind spot causes). The rest of this guide covers both, and what fixes each.
Why does a healthy service flip to “down”?
A healthy service flips to “down” when the monitor reports a false positive: an alert or status change with no real user-facing problem behind it. The cause is rarely a mysterious flake. It is usually one of three things.
- A single failed probe treated as a real outage. Networks drop packets, a probe server has a bad second, and your host has a brief GC pause. A monitor that flips state on the first failed check alerts on noise constantly. 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. Suppose the vendor's single check location has a routing problem to your host. Your status page then reports you as down to the entire world, while every real visitor reaches you fine. The “outage” sits between the vendor and its own probe, not between your customers and you.
- Checks that don't know about planned maintenance. A deploy can take an endpoint down on purpose for 90 seconds. To a monitor with no maintenance window, that looks identical to an unplanned outage. It alerts and opens an incident for something you already knew about.
The fix for the first cause is to require a failure to persist before treating a check as really down. RealUptime Status requires a region to fail continuously for 3 minutes, with every probe since the first failure failing, before that region's state flips to down. A single successful probe flips it back to operational. Brief network failures between a probe and your service typically last well under a minute. A dropped connection therefore updates the raw history but does not, by itself, open an incident or fire an alert.
The fix for the second cause 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 cause is a maintenance window the monitor respects. A scheduled window suppresses the outbound alert for a check tied to it. The underlying check history and public incident record stay accurate underneath. The page never lies by staying artificially green, and it does not 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 from one cloud region only proves reachability from that one place. That region is usually wherever the monitoring vendor's own infrastructure happens to live.
Consider the failures such a check cannot see: a regional outage, a bad deploy that only breaks your Asia-Pacific edge, a CDN node failing in Europe, or a database replica falling over in one availability zone. Every customer in the affected region sees errors. The single distant check keeps passing, and the badge stays green.
The pattern is common enough that a small industry exists to catch it. Third-party monitoring firms 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 do multiple regions buy you?
Multiple regions turn one ambiguous data point into a comparison. Say four regions check the same URL, three report healthy, and one reports down. You now have real evidence about where the problem is. Three patterns cover most cases.
- One region down, others healthy. This is a genuine regional or network-path issue. Investigate it, and tell the customers actually affected instead of everyone.
- All regions down at once. This is a real, global outage. The failure is not about geography, so treat it as a full incident immediately.
- One region flickers alone, briefly, then recovers. A routing blip between that specific checker and your host is more likely than a customer-facing problem, especially if it does not clear the two-consecutive-failure threshold.
The regions must be real and independent, not one location with the results copied four times. The per-region result must also be shown, not collapsed into a single badge before it reaches the page. A tool that checks from four regions internally but publishes one operational/degraded/down state has 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
Evidence should decide who gets paged, in the same way it decides what the public page shows. One failed probe from one region is not an incident, so page no one for it. A region that has failed for 3 minutes straight, with the others still healthy, deserves a Slack message to your team. If the service is customer-facing, update subscribers on the specific region affected. Every region failing at once deserves 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. Google's SRE book states the standard for pages in Monitoring Distributed Systems: every page should be actionable.
How RealUptime Status handles this
RealUptime Status checks every monitor from four regions on Free (US-East, US-West, Europe, and Asia-Pacific), eight on Pro and ten on Business. Checks run as often as every minute, and every 30 seconds on Business. The public page publishes each region's state separately instead of collapsing them into one badge.
A region only flips to down after it has failed continuously for 3 minutes, and it recovers on the first success. A transient blip therefore updates the history without opening an incident or alerting anyone. When a real transition happens, an incident drafts automatically with the specific region named in the text. See how this compares to the tool you use today on the comparison pages.
Next