Uptime is not a yes/no question

A reader asked us why a server was marked unreachable when it opened fine in their browser. They were right, and so were we. The server answers most of the time — and drops the rest.

One server, two truths

We sent it twenty-five requests. Roughly a third came back like this:

curl: (56) Recv failure: Connection reset by peer

Not a timeout. Not a TLS problem. The connection opens, the request goes out, and the server hangs up mid-answer. Spacing the requests three seconds apart changed nothing, so it is not rate limiting. Our own measurements agree: 31% of probes to that host fail.

Why a single check lies

If a server fails one request in three, then checking it once tells you almost nothing. You will call it healthy two times out of three and broken the third — and both answers are equally wrong, because the truth is a percentage, not a state.

It gets worse for alerts. Two failures in a row look like an outage. At a 31% failure rate, two in a row happens about 9% of the time — roughly once a day if you check every two hours. That is not an outage. That is arithmetic.

How common is this?

We scanned the catalog for servers that are neither reliably up nor reliably down. About 180 sit in the unstable middle, failing somewhere between 10% and 90% of the time. It is a small share of the ecosystem — and a large share of the confusion.

What to do with it

• If you are choosing a server: read the percentage, not the badge. A server at 70% will fail in production, quietly, one call in three.
• If you run a server: intermittent connection resets usually point at a proxy or load balancer in front of the app, not the app itself. The application logs will look clean.
• If you build monitoring: never decide on one sample. Require a streak, and say the rate out loud.