How to Read Uptime Reports and Spot Fake Downtime Claims

To read uptime reports properly you have to separate what was measured from what was claimed, and the only way to do that is to look at the method: which protocol, which vantage point, which threshold counts as down, and how the samples were aggregated. A host advertising a very high availability figure is telling you about its own measurement choices as much as about its network, and those choices are usually visible if you know where to look.

Start with the protocol, because the protocol defines the question

Most availability numbers come from one of three checks, and they do not measure the same thing.

An ICMP echo check answers "does this address reply to ping". It is cheap, it runs everywhere, and it is the weakest signal you can collect. Plenty of production systems drop ICMP by policy while serving traffic perfectly, and plenty of routers reply to ICMP while the service behind them is dead. If a report is built only from ping, a low number may say more about firewall rules than about outages.

A TCP connect check answers "can I complete a handshake on this port". That is a much better proxy for a web service, because it exercises the listening socket. It still says nothing about whether the application returned a valid response.

An HTTP check answers "did the request come back with an acceptable status and body". This is the only one of the three that can catch a web server that accepts connections and then returns errors, which is a common failure mode after a bad deploy. If a host's public status page does not say which of these it uses, treat the figure as unverified.

$ curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' \
    https://example.com/health
200 0.184

Run that against your own site from a few places and you have the beginnings of your own baseline. The -w format string is where the useful data lives: status code, total time, and if you want it, %{time_connect} and %{time_starttransfer} to split the handshake from the first byte.

How to read uptime reports when the aggregation hides the outage

The interesting dishonesty is rarely in the raw samples. It is in how they are rolled up.

Ask what the sampling interval is. A check every minute produces a different picture from a check every fifteen minutes, and neither is wrong, but a short outage is far more likely to be missed by the sparse check. If a report shows a suspiciously clean line, the interval is the first thing to question.

Ask what counts as down. Many monitors mark a target down only after a run of consecutive failures, which is a sensible way to suppress flapping but also a way to erase short incidents entirely. A monitor requiring three failed checks at five minute intervals will never record an outage shorter than roughly a quarter of an hour, no matter how real it was for your users.

Ask how the percentage is computed. There is a large difference between time weighted availability, where each failed interval contributes its duration, and sample weighted availability, where each check counts the same. They diverge whenever the sampling is uneven, and uneven sampling is common after a monitor restarts or a probe goes offline.

Ask which vantage points are included. A single probe inside the same datacenter as the server will report near perfect availability while your customers on a different continent see timeouts on a peering path. Multi region monitoring exists precisely because "the server is up" and "the server is reachable from where the users are" are different claims.

Read the raw data, not the dashboard

Any serious monitoring system exposes its history as data, and that is what you should be reading. The dashboard is a rendering choice. The underlying series is the evidence.

With Prometheus style tooling, a probe exports a value per target, and you can query the failure rate directly rather than trusting a summary widget. The expression below computes, over the last day, the fraction of samples where the probe reported failure. Adjust the metric name to whatever your exporter uses.

avg_over_time(probe_success{job="blackbox"}[24h])

The result is a fraction between zero and one. What matters is not the single number but the shape around it: query the same expression at a one hour range and you will see which hours carried the failures. A host reporting a strong monthly figure with one bad hour buried inside it is telling a different story from one with failures spread evenly, and only the finer resolution shows you which you have.

For a quick sanity check from a shell, a loop that logs a timestamp and a status code is often enough to catch a pattern the summary hides.

while true; do
  printf '%s %s\n' "$(date -u +%FT%TZ)" \
    "$(curl -sS -o /dev/null -w '%{http_code}' https://example.com/)"
  sleep 60
done >> uptime.log

Leave that running and you have your own time series, independent of anything the host publishes.

Status pages and the vocabulary of incident reports

When you read a status page, read the wording of the incident entries rather than the headline availability figure. Phrases like "degraded performance", "partial outage" and "elevated error rates" are not standardized, and each provider decides where the line falls between an incident and a blip that never gets posted. A page that only records full outages will look cleaner than one that records latency spikes, without either being more or less available in reality.

Check the timestamps on the incident entries against your own logs. If your monitoring shows a gap that the status page never mentions, that tells you something about the reporting threshold. If the entries line up, the page is doing its job.

Also check whether the monitor and the monitored share a failure domain. A status page hosted on the same infrastructure as the service it describes will go dark at exactly the moment you need it, and the absence of an incident entry during your own outage is not evidence that nothing happened.

What to do next

Set up your own external check from at least two locations outside the host's network, point it at a URL that exercises the application rather than a static file, and keep the raw samples rather than only a rolling percentage. When you evaluate a host, ask which protocol the check uses, what the sampling interval is, how many consecutive failures trigger a down state, and whether the published figure is time weighted. If those answers are not available, weight your own measurements far more heavily than any number on a marketing page, and treat a clean line as a prompt to look at the method rather than a conclusion.