What each monitoring status actually means
Most monitoring tools only have two states worth naming: up and down. That is a simplification that hides real, different facts. Here is what each status we actually show means, and why the two nobody else bothers to explain, blocked and not monitored from this region, are not the same thing as down.
Five states, five different claims
A monitoring result is a claim about what a probe observed. There are five distinct claims worth keeping separate:
- Operational. The probe reached the service and got a normal response.
- Down. The probe reached out and got a failure, or nothing, and it cleared the threshold that rules out a single dropped packet.
- Blocked. The probe got a response, but the response looks like access control aimed at automated traffic, not a real outage. This is a claim about our probe's reception, not about the service's health.
- Awaiting data. This region is supposed to check this service and will produce a reading, there just isn't one yet. Temporary, by definition.
- Not monitored from this region. This region will never produce a reading for this service, because it was never configured to check it from there. Not temporary.
Folding any of the last three into “down” would be a lie about what we actually know. Folding them into “up” would be a different lie. Both matter, which is why we show all five.
Blocked: a response, just not the one automated traffic gets
A blocked reading means the probe got something back, a 403, a 429, a redirect loop, or a timeout we could rule out as a real outage against a second endpoint, rather than a normal success or failure. That tells us something about how the target treats automated requests from our probe's network range. It does not tell us whether a real visitor, arriving from a browser instead of a monitoring probe, is having any trouble at all.
Some blocked readings still carry a useful signal underneath the block. If the probe completed a real connection and TLS handshake and got an actual HTTP response with a measured latency, that is positive evidence: the edge is up and reachable, we just were not allowed through the specific path automated checks get filtered on. Other blocked readings get nothing back at all, connection refused or timed out with no response, and those genuinely tell us less. Treating every block as equally uninformative would throw away the first kind of signal; treating every block as equally conclusive would overstate the second kind. We keep the two apart rather than averaging them into one number.
The practical upshot: a blocked reading is worth investigating, not worth panicking over. It is evidence about the relationship between a probe and a target, and the fix (if there is one) is usually an allowlist entry, not an incident.
Not monitored from this region: a decision, not a gap
“Not monitored from this region” and “awaiting data” look similar at a glance, an empty-looking cell where a status usually goes, but they are opposite facts. Awaiting data means a reading is coming: the region is configured to check this service and simply hasn't produced a result yet, which resolves itself as soon as the next check runs. Not monitored means no reading is ever coming from that region for that service, because it was deliberately left out of the checked region set. A US-only service checked only from US-East and US-West will never produce a Europe or Asia-Pacific reading, not because something is broken, but because nobody asked it to check from there.
Rendering “not monitored” as if it were “awaiting data” would read as a promise that a reading is coming eventually. It never will, and saying otherwise would be exactly the kind of quiet inaccuracy a monitoring product exists to avoid. Rendering it as green (“operational”) would be worse: it would claim a positive result we never actually took. The honest option is a state of its own, said plainly.
Why the distinction is worth keeping instead of collapsing
A dashboard that only has “up” and “down” has to force every reading into one of the two, which means a blocked probe becomes a false “down” and a never-checked region becomes either a false “down” or a false “up,” depending on which way the tool decided to round. Neither rounding is honest, and the reader has no way to tell, from the collapsed badge alone, which kind of uncertainty they are actually looking at. Five distinct labels cost nothing extra to compute; they cost only the discipline of not rounding a specific fact down to a generic one.
How realuptime shows this
realuptime's outage tracker and status pages render operational, down, blocked, awaiting data, and not monitored from this region as five separate states, each with its own label, never collapsed into a single badge before it reaches the page. A blocked reading with an actual response is called out separately from one with none, and a region a service was never configured to check from renders as not monitored, never as an absent or invented reading.
Next