A rate that could only ever say 100 percent
The directory shows, for each server, the share of days on which its endpoint answered us. The filter on /servers labels it “Reachable on observed days (90-day window)”, and offers three bands: 99% or more, 90–98%, and below 90%.
On 2026-09-23, all 833 servers in the directory showed 100 percent. The two lower bands were always empty.
How we found it
We were fact-checking a post about how often we check before publishing it. The draft described the rule correctly: a day on which any probe went unanswered was left out of the calculation, the same as a day we never got to.
The reviewer checking that sentence against the code noticed what it implied. Our reachability check never records a failure. When an endpoint does not answer, the check is recorded as unverified: we could not conclude. So every day on which an endpoint failed to answer was left out, and every day left in was a day on which it answered. The figure could only be 100 percent, or absent.
One read-only query confirmed it: 833 rows, all 100, no other value.
The figure was not false in a narrow sense. It said exactly what the rule computed. But a reader who sees 100 percent next to a server takes it to mean the server answered every time, and that is something this figure could not tell them.
What we changed
The question was which of the days we could not conclude were the server’s doing, and which were ours.
A day now counts as unanswered when any reachability check that day got no answer from the endpoint:
- the host name did not resolve;
- the connection failed;
- no complete response arrived within the probe’s time budget;
- or the handshake was answered with an HTTP 5xx.
A day on which the only checks that could not conclude were our own doing is still left out, counted neither way: we were rate-limited, or our own policy declined to connect.
The directory switched to this rule on 2026-09-24. Two parts have their own start dates. A failed connection could only be told apart from our own problems after a probe update on 2026-09-27, so failed connections count from that day. The handshake rule counts from 2026-09-23, the first day the probe recorded the HTTP status of a failed handshake. The methodology page states the rule with the same dates.
What it looks like now
On 2026-09-30, the 1,470 servers in the directory:
| reachable on observed days | servers |
|---|---|
| 99% or more | 1,338 |
| 90–98% | 92 |
| below 90% | 40 |
Each of the 92 in the middle band has one unanswered day, out of 14 to 19 days observed. The median server in the directory has been observed for 14 days, and 633 have been observed for three days or fewer, so a single day moves the figure a long way. That is why the number of days counted is shown next to every percentage.
What it still does not say
Almost every server in the directory is probed every twelve hours. A day on which both probes were answered can still have had an outage between them, and we say so. The figure describes the moments we looked. It is not a measure of availability between them.
Where the numbers come from
The 2026-09-23 figure is a read-only query against the directory view, grouped by the percentage. The 2026-09-30 figures are a read-only query on the same view at about 20:05 UTC, grouped into the three filter bands, with the median and range of observed days in each band. “One unanswered day” is derived from each server’s percentage and its count of observed days.