4.3 million uptime checks: what real availability data looks like

The dataset: between August 2025 and July 2026, ViewPeek's monitoring agents ran 4,337,525 HTTP uptime checks, 1,096,728 pings, and 15,177 SSL certificate checks against 21 production monitors — a mix of our own portfolio and customer targets, reported here only in aggregate. One honesty note before the findings: the dataset has a gap in March–April 2026, when the monitoring infrastructure itself was being migrated. We're publishing what the data shows, including the parts that flatter nobody.

Finding 1 — Uptime is a barbell, and averages lie

The single most striking pattern: no monitor in the entire dataset lived between 1% and 99% uptime. Every target was either alive — 17 of 21 monitors at 99.4% or better, most at 99.97%+ — or effectively dead, with four monitors at exactly 0% (abandoned domains, DNS that no longer resolves, infrastructure that was simply switched off while its monitor kept checking).

That makes "average website uptime" a nearly meaningless number. Our fleet-wide mean is 99.28%, but that figure describes nothing real: it's three-nines sites blended with corpses. The median monitor recorded 99.995%. If you're benchmarking your own site, compare against the median of living sites — and treat any sustained dip below 99% not as degradation but as a sign something is structurally wrong (billing lapse, expired domain, decommissioned box) rather than a flaky app.

Finding 2 — "Down" almost never means "crashed"

Folklore says downtime looks like an error page. The data says otherwise. Of the 31,328 failed checks:

Five out of six failures happen before your application code runs at all. The practical consequence: monitoring only your app's health endpoint misses most of what actually takes sites offline. Reachability, DNS, and certificate validity are where the real risk lives. The 401/403 slice carries its own lesson — a meaningful share of "downtime" was sites accidentally blocking their own monitoring, which is worth checking before you trust a red dashboard.

Finding 3 — Healthy sites are fast, and consistently so

For successful checks, the response-time distribution was tight: median 21 ms, 95th percentile 243 ms, 99th percentile 447 ms (EU agents checking predominantly EU-hosted targets — your geography will shift the absolute numbers, not the shape). The distribution barely moved by hour of day: the median was 21 ms at 3 a.m. and 21 ms at 3 p.m. Modern hosting doesn't have a rush hour at this scale; if your site's response time swings with the clock, that's a capacity signal worth investigating, not normal weather.

Finding 4 — SSL automation works, with a tail

Every certificate in the dataset — across 15,177 checks — was an automated Let's Encrypt certificate. Renewal automation kept most observed certificates in the comfortable 30–90-days-remaining band. But automation is not a guarantee: we observed one certificate reach 0 days remaining — checked on the very day it expired. Renewal cron jobs fail silently; the certificate does not. That tail case is exactly why expiry alerts at 30, 14, and 7 days are worth having even when "renewal is automated".

Methodology & caveats

• Window: 2025-08-15 → 2026-07-19, with a March–April 2026 gap (monitoring infra migration). Monthly volumes otherwise ~480–500k checks.
• 21 HTTP monitors at 1–60-minute intervals; results aggregated, no customer targets identified.
• Failure classes derived from stored error messages and HTTP statuses; "connection/DNS" includes dial, resolution and TLS-connect failures.
• Response-time percentiles computed over successful checks only.
• This data is citable — link to this page. We'll re-run the numbers periodically as the fleet grows.

Monitor your own site with ViewPeek — free, no card required →