HTTP response code distribution in 2026: why every such statistic is wrong

We hold two sets of response codes, and they give different pictures — which is itself the answer to the question.

Tool check history: 39,660 records, of which 98.93% are code 200. It reads like a sensation: "the web works almost without errors". In fact it is an artefact of method: our tools follow the redirect chain and record the code of the final page. Every 301 and 302 along the way becomes a 200 at the end.

Monitoring checks: 1,789,058 records, and a different picture. Monitors record what they got, and the distribution becomes meaningful at once:

The first row is the most substantive. More than one check in five produced no HTTP code at all: the connection never established, the wait expired, name resolution failed. Such cases never enter "response code" statistics because there is no code — and that is the commonest form of unavailability.

Here is the main reason a "distribution of response codes on the web" cannot be measured. Look at how many distinct sites produced each code:

Code 307 appears twenty thousand times — and all twenty thousand from one site, checked every minute and answering with a redirect every minute. The same holds for 418 and 400.

Computing "the share of code 307 on the web" from this data yields 1.48% — and that would be an entirely invented quantity, reflecting one server’s configuration multiplied by how often it is polled.

The only code with genuinely distributed presence is 502, across nineteen distinct sites. That is the real signal: a gateway failure happens to many a little, rather than to one a lot.

Three mechanisms spoil it independently, and each suffices on its own.

First: following redirects. Any tool behaving like a browser consumes 3xx and shows the final code. Our own check history illustrates it: 98.93% code 200, while the redirects have gone nowhere.

Second: polling frequency. A site checked once a minute produces sixty times more rows than one checked hourly. The distribution ends up weighted by polling interval rather than by number of sites.

Third: sample composition. People monitor what matters and usually works. Abandoned domains and broken sites never enter such a sample — and they are exactly what would produce the 4xx and 5xx.

The conclusion: any publication of "the distribution of response codes on the web" measures the method of measurement rather than the web. We could have published our 98.93% as a headline figure — and it would have been untrue about the web while the data was entirely true.

Quantities that genuinely are measurable and useful on your own data:

1. The share of checks with no answer at all. Ours is 22.27%. That is a state of unavailability which carries no code and therefore drops out of every code-based statistic — while being the most important of them.
2. Distinct hosts per code, not occurrences. One site with twenty thousand identical answers should not outweigh twenty sites with one answer each.
3. Your own series over time. Comparing today’s distribution against your own from a month ago is sound, because the method did not change. Comparing against somebody else’s is not.
4. Redirect chain length separately. It is lost when redirects are followed, and it is exactly where superfluous hops hide. We examined that in a separate measurement.

To see the codes and chain for your own address, use the redirect checker; for a reference of the values, the response code list.