What 1.12 million health checks reveal about production websites

Over a single 7-day window in May 2026, automated probes against 505 production websites returned 1,122,309 individual HTTP responses. The headline finding: more than one in four monitored sites returned at least one detectable error to a visitor. This report breaks down what those errors actually were, where they came from, and what the patterns tell us about the state of web reliability today.

The 27% problem

Across 505 websites monitored continuously, 139 returned at least one non-success response during the week. This isn't a measure of total downtime; most affected sites worked correctly the vast majority of the time. But each one had at least one window where a real visitor would have hit a broken page, a server error, or a completely blank response.

The number changes depending on what you count as an "error." If you include WAF blocks against the probe (which are intentional and correct behaviour from the customer's perspective), the figure rises. If you exclude rate-limiting and only count visible breakage, it drops slightly. The 27% figure represents URLs that returned any non-2xx, non-3xx response, even once.

What the errors actually were

Looking at every individual check, not every site, the response code distribution is dominated by working pages, but the tail contains a mixture of intentional and unintentional failures:

HTTP code	Count	Share	What it is
200 OK	1,061,001	94.5%	Working
403 Forbidden	50,488	4.5%	WAF block (expected)
503 Service Unavailable	3,420	0.3%	Real backend issue
404 Not Found	3,226	0.3%	Missing page
530 Cloudflare	1,728	0.2%	Origin unreachable
500 Internal Server Error	1,614	0.1%	Real app error
429 Too Many Requests	742	0.1%	Rate-limited
Other (3xx, network)	58	0.0%	Edge cases

A naive monitor would treat every non-200 response as downtime and report a misleading 5.5% failure rate. Most of those non-200s are intentional WAF behaviour from sites correctly rejecting probe traffic that doesn't match expected patterns. Properly classified, the real backend or application error rate is around 0.45% of checks. That sounds small until you remember it represents thousands of real failures that real visitors would have seen.

Beyond status codes: invisible errors

HTTP 200 doesn't mean a page is working. It just means the server responded. Some of the most common production issues return 200 OK while actually being broken:

Content pattern	Detected	What it means
Empty page (no <title>, no <h1>)	3,054	Page rendered but content missing
Database connection error in body	22	Application returned a DB error page
PHP Fatal / Warning / Notice in output	2	Server-side errors leaked to the user

Three thousand blank pages. Twenty-two database errors visible to the public. Two PHP fatal errors that anyone could have seen. None of these would be detected by a basic "is the server pinging back?" monitor. This is the gap between "the server is up" and "the website is working."

Where the flakiness actually lives

Looking at the 139 sites that had at least one error, the patterns fall into three distinct buckets:

The largest group, roughly three quarters of all flaky sites, are customer WAF configurations being aggressive against the probe. The customer's WAF correctly identifies repeated automated requests and starts rate-limiting them with 403 responses. This isn't a hosting infrastructure issue; it's the WAF doing its job. But it counts as a "failure" from the monitor's perspective and would equally count as a failure for any other automated client (search engine crawlers, third-party integrations, monitoring tools, accessibility scanners).

The remaining quarter splits into two smaller groups: backend instability (sites that periodically return 5xx errors, suggesting overloaded application servers, database timeouts, or deploy windows) and origin connectivity issues (sites where Cloudflare can't always reach the origin server, returning 530s). Both categories represent real problems that the site owner probably wants to know about.

Response times: the long tail

Beyond binary success/failure, response time tells its own story. Median response time across all checks was 1.64 seconds (full-page render, not just headers). The 99th percentile was 9.87 seconds, with maximums reaching 60 seconds.

The shape of the distribution is more informative than any single number. Median 1.64s is normal for a content site doing real database queries and template rendering. The jump to p99 9.87s reveals that about 11,000 checks per week return responses slower than 10 seconds. For most visitors on slow connections or mobile networks, that's effectively a timeout. They close the tab.

Interestingly, failed responses came back faster than successful ones on average (1.17s mean for failures, 2.16s for successes). This is the signature of WAF blocks: a 403 returned immediately at the edge takes less time than rendering a full HTML page with database queries. It's a useful tell when interpreting whether failures are "slow" (real infrastructure issues) or "fast" (intentional rejection).

What this means for site owners

Three takeaways from the data:

1. "The server is up" is not the same as "the site is working"

A non-trivial portion of the issues found weren't down to the server being unavailable. They were the server returning HTTP 200 with broken content. Empty pages, leaked database errors, missing templates. Without content-level inspection, these slip through every uptime monitor that only checks status codes.

2. Most "failures" are actually working as intended

The majority of non-200 responses in this dataset were customer-configured WAF rules behaving correctly. A monitor that doesn't understand the difference between intentional protection and real downtime generates false alarms, which leads to alert fatigue, which leads to the real alerts being ignored. Detection categorisation matters as much as detection itself.

3. The long tail is where the surprises live

Median and average response times tell you about the typical case. The 99th percentile, the slow URLs, the flaky 5% — that's where production reality differs from your assumptions. Eight of the ten slowest URLs in this dataset shared a common naming pattern, suggesting they shared infrastructure. Without per-URL breakdown, you'd never know to look.

Methodology

The same monitoring infrastructure that produced this data is available to any website operator through wedos.online. If you'd like to see what your own site looks like under continuous content-level monitoring, the next section explains how.