Five states, five different claims
A monitoring result is a claim about what a probe observed. Five distinct claims are 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.
What does a blocked reading mean?
A blocked reading means the probe got something back, but not a normal success or failure. The response might be a 403, a 429, a redirect loop, or a timeout we could rule out as a real outage against a second endpoint.
A blocked reading tells us 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. Suppose 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, and we 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. Those readings 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. A blocked reading is evidence about the relationship between a probe and a target. The fix, if there is one, is usually an allowlist entry, not an incident.
Is “not monitored” the same as “awaiting data”?
No. “Not monitored from this region” and “awaiting data” look similar at a glance, since both leave an empty-looking cell where a status usually goes. They are opposite facts.
Awaiting data means a reading is coming. The region is configured to check this service and 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 the region 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. Nothing is broken. Nobody asked the service 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 not collapse the states into up and down?
A dashboard with only “up” and “down” has to force every reading into one of the two. A blocked probe becomes a false “down.” 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. From the collapsed badge alone, the reader has no way to tell which kind of uncertainty they are 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 state has its own label and is 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. A region a service was never configured to check from renders as not monitored, never as an absent or invented reading.
Next