State of Web Reliability · Q2 2026
Findings from monitoring 505 production websites continuously over a 7-day window, with full content-level inspection.
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.
27% of monitored websites returned at least one detectable error during the 7-day window, and most site owners would have had no way of knowing without active monitoring.
Across 505 websites monitored continuously, 139 returned at least one non-success response during the week. This is not 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.
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 does not 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.
HTTP 200 does not 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."
The standard hosting monitor checks for HTTP 200. A 200 OK that returns a database connection error page satisfies that check. Your visitors see a broken site. Your monitoring tells you everything is fine.
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 is not a hosting infrastructure issue; it is 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 cannot always reach the origin server, returning 530s). Both categories represent real problems that the site owner probably wants to know about.
Beyond binary success or 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.
Latency percentiles across all checks. Track scaled to 10s. Max excluded for readability (max: 59.77s).
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 is 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 is a useful tell when interpreting whether failures are slow (real infrastructure issues) or fast (intentional rejection).
A non-trivial portion of the issues found were not 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.
The majority of non-200 responses in this dataset were customer-configured WAF rules behaving correctly. A monitor that does not 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.
Median and average response times tell you about the typical case. The 99th percentile, the slow URLs, the flaky 5%: that is 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 would never know to look.
The same monitoring infrastructure that produced this data is available to any website operator through wedos.online. If you would like to see what your own site looks like under continuous content-level monitoring, the section below explains how.
The infrastructure that generated this report is available to any site owner. Continuous content-level monitoring, anycast probes from EU-only nodes, alerts when something actually breaks, not just when the server stops responding.
See wedos.onlinePublished by WEDOS, a.s., 18 May 2026. This is the Q2 2026 edition of the State of Web Reliability report; future editions will track quarter-over-quarter changes in the same metrics across an expanded URL pool. Source data: 1,122,309 individual HTTP checks across 505 production URLs, monitored continuously from 11 to 18 May 2026 by the WEDOS audit probe infrastructure. Dataset excludes 48 URLs identified as dead (parked domains, abandoned projects) prior to analysis.