What Uptime Monitoring Actually Measures

Sep 21, 2026

Every monitoring tool will happily show you a big green number. What that number means depends entirely on what the check does, where it runs from, and how often it fires. Two tools can report 99.9% and 97.2% for the same site in the same month, and both can be telling the truth.

It is worth being precise about this, because uptime is the number you put in front of customers.

A monitor measures reachability, not correctness

The most common check is an HTTP request to a URL, with a pass condition of “responded with 2xx within the timeout”. That answers one question: could a machine on the internet get a response out of your server?

It does not answer whether the page rendered, whether the checkout worked, whether the search index was stale, or whether logged-in users saw an error. A site can serve a perfect 200 OK on the homepage while every authenticated request fails. The monitor will call that 100% uptime.

This is not a flaw, it is a boundary. Reachability is cheap to measure from outside, needs no credentials, and catches the majority of hard outages. Just do not mistake it for a claim about your application being correct.

The check interval defines your resolution

If a monitor checks every five minutes, the shortest outage it can see is roughly five minutes long, and the shortest one it will reliably see is longer than that. A 90-second outage between two checks is invisible. It happened, users hit it, and your uptime report will not mention it.

Shorter intervals raise resolution and raise load. One request a minute against your own server is nothing; one request a minute against a rate-limited third-party API is a different conversation. Pick the interval from how quickly you need to know, not from how small a number you can set.

Where the check runs from is part of the measurement

A monitor sitting in the same data centre as your server is testing your application. A monitor on another continent is testing your application plus DNS plus your CDN plus a long chain of networks you do not own.

Both are useful and they are not the same measurement. A single-location monitor that goes red might be reporting your outage or its own network’s bad afternoon. This is the single biggest source of alerts that turn out to be nothing.

Confirmation changes the number

Most tools do not alert on the first failed check. They retry, often from a second location, and only declare an incident when the failure repeats. That is the right default - it removes a large class of noise - but it also means your “down at 14:32” timestamp is really “first failed check at 14:30, confirmed at 14:32”.

When you compare uptime figures between tools, confirmation logic explains a surprising amount of the difference.

What to do with all this

Write down, for each monitor, the sentence it actually supports. Something like: “an HTTP GET to the homepage from Frankfurt returned 2xx within 10 seconds, checked every minute, confirmed twice before alerting.”

That sentence is your real SLA evidence. It tells you what you would still be blind to, which is usually the more interesting half: authenticated flows, background jobs, slow-but-not-failing responses, and everything that happens after the first byte.

Uptime is a useful number. It is only useful when you know which question it answered.