The Digital Hosting Uptime Study

What we measure

Every five minutes, monitoring probes in the United States, Canada, Europe, and Asia-Pacific request each provider's primary website over HTTPS. For each check we record whether the request succeeded (HTTP 200–399 within 30 seconds, following redirects) and how long the response took, per region. A provider is only marked unavailable when multiple probes in a region agree — a single flaky network path never counts as downtime. That is roughly 288 checks per provider per day, per region, for 90 days: about four million measurements across the study.

Measurement runs on FourSight, the uptime-monitoring platform built by TetraCore, the same company that operates this site. We're disclosing that relationship up front: it's why we can afford to run four-region quorum monitoring against 37 companies, and none of the monitored providers has any relationship with the measurement infrastructure.

What we deliberately do not claim

This study measures each provider's primary web presence — the site you visit to sign up, manage services, and reach support. It does not measure the uptime of customer servers hosted on these platforms. Those are different infrastructures: a host's marketing site can go down while customer workloads hum along, and vice versa. We think a company's own front door is still worth measuring — several of these providers host their main site on the very infrastructure they sell, and a company that can't keep its own site fast and reachable is showing you something — but we will never present these numbers as "hosting uptime." A phase-2 study measuring real hosted workloads (a test site on every provider) is on the roadmap if this one proves useful.

Who is being monitored

Shared, managed & dedicated hosts (16)

Hostinger, Cloudways, SiteGround, DreamHost, A2 Hosting, Bluehost, InMotion Hosting, Kinsta, WP Engine, Rocket.net, Pressable, Flywheel, Nexcess, Liquid Web, Hivelocity, Rackspace

Cloud & VPS platforms (7)

DigitalOcean, Vultr, Linode (Akamai), Hetzner, OVHcloud, Scaleway, AWS Lightsail

Email hosts (7)

Google Workspace, Microsoft 365, Fastmail, Proton Mail, Zoho Mail, Migadu, MXroute

Domain registrars (7)

Porkbun, Namecheap, Cloudflare Registrar, Dynadot, Hover, Gandi, Name.com

The list is exactly the set of providers reviewed on this site — nobody paid to be included and nobody can pay to be excluded.

Update, September 2026: the site has since added coverage of GoDaddy, IONOS, Spaceship, and Infomaniak. They are not part of this study. The 37-provider roster above was frozen when the methodology was published, and adding providers mid-study would mean comparing unequal observation windows — a provider that joined in September would have "missed" incidents earlier entrants were measured through. Newly covered providers are candidates for a second monitoring wave with its own methodology published before its results, after this study's 90-day window closes.

Update, September 25, 2026 — Cohort 2 monitoring has started, unpublished. The site added KnownHost, NixiHost, Krystal, and Zume (the r/webhosting moderators' shortlist), then ScalaHosting and Ultra Web Hosting the same day, then 20i, AccuWebHosting, UltaHost and HostColor on September 28, and now monitors those ten plus IONOS, Spaceship, and Infomaniak as a separate monitor group — same 5-minute interval, same four regions, same quorum rule, homepage plus robots.txt edge target for each. Nothing from that group appears in this study's figures or in the interim report, and none of it will be published until Cohort 2 has its own methodology page and a full observation window. Two disclosures already: GoDaddy is not monitored because godaddy.com returns 403 to every automated request, including robots.txt; and the Spaceship and Zume homepage monitors were paused within their first check cycle after all four regions received HTTP 403 in under 120 ms (the bot-block signature described below) — their robots.txt edge monitors passed and continue. Cohort 2 also inherits the 403-as-down quorum behaviour this study documents; the quorum hardening that treats blocked responses as invalid rather than down is a prerequisite before any Cohort 2 number is reported.

Day-one finding: a fifth of providers block non-US automated traffic

Within hours of starting, the study produced its first result — about bot policy, not uptime. Seven of the 37 providers (Bluehost, Cloudways, InMotion Hosting, Linode, Namecheap, Nexcess, and Vultr) answered our US probes normally while rejecting the same requests from Canadian, European, and Asia-Pacific probe addresses with HTTP 403 bot-mitigation challenges. Two of them — Bluehost and Cloudways — challenge even robots.txt, the file explicitly published for automated readers.

Those 403s are edge security decisions, not outages, so counting them as downtime would be dishonest. We adjusted the methodology the same day, and disclose it here rather than quietly: the affected providers' homepage response-time measurement continues from the US region only, and where a provider's edge serves robots.txt globally (InMotion Hosting, Namecheap, Nexcess — plus WP Engine and Dynadot, which showed milder regional challenges), a four-region availability check runs against that instead.

Update, August 17: Dynadot's regional challenges turned out not to be so mild — its homepage has rejected every Asia-Pacific probe with a 403 since day one, while Canadian and European probes stayed clean. Counting a standing bot policy as downtime would be dishonest, so we removed the Asia-Pacific region from Dynadot's homepage monitor on August 17. Its four-region availability continues to be measured against its globally-served robots.txt.

Within hours, the picture sharpened further: Linode and Vultr began rejecting our US probe as well — reputation-based bot scoring flagged the measurement addresses entirely, Vultr including robots.txt. The same requests from a residential connection still return 200, so this is IP-reputation policy, not an outage. Rather than publish numbers we can't stand behind, both are classified as "blocks automated measurement": Vultr's monitors are paused entirely, and Linode's homepage monitor is paused — though Linode's globally-served robots.txt still answers all four regions, so that edge availability check continues to run. We will retest at each report date and say so if the policy changes. Bluehost and Cloudways remain measurable from the US only. So the day-one scoreboard: 33 of 37 providers fully measurable, four with partial or no automated measurability — which is itself a finding, and it will be reported as one.

Update, September 14: the bot-wall problem escalated mid-study, and this update discloses both the incident and the correction. From August 31, 19:15 UTC, the five providers measurable only from our US probe (Bluehost, Cloudways, InMotion Hosting, Namecheap, Nexcess) began answering that probe's network address with HTTP 403 — reputation-based blocking of the measurement IP, the same phenomenon that took Linode and Vultr out on day one. Because those monitors had no other region to outvote the block, they recorded ten days of false "downtime" before our September 10 audit caught it. Every request in the window returned 403 in under 100 milliseconds — a bot-wall's signature, not an outage's — and all five sites answered normally from residential connections throughout. That window is excluded from all study statistics, the five US-only homepage monitors are retired, and availability measurement for InMotion Hosting, Namecheap, and Nexcess continues unbroken on their four-region robots.txt checks (one further Namecheap window, September 8 18:10 → September 9 07:31 UTC, showed the same 403 signature on that check and is likewise excluded — distinct from its two real outages, which returned HTTP 503).

Bluehost and Cloudways are dropped from the study as of September 14. Both now block our probes entirely — homepage and robots.txt alike, from all four regions — leaving no honest way to measure them. Alongside Vultr's day-one block, that makes three of 37 providers that do not permit independent automated measurement, which the reports treat as a finding in its own right. The study continues with 34 measured providers. Two smaller notes for the record: the five providers above also produced a 40-minute false alarm at study start on August 8 (non-US probes bot-blocked before those monitors were narrowed to US-only), now formally excluded; and Microsoft 365's "degraded" time in September is largely a measurement-threshold artifact (responses returning HTTP 200 from every region at ~3.0–3.2 seconds, oscillating around our 3-second threshold) — flagged for tuning, and degraded time is never counted as downtime in any case.

Update, September 23: the interim findings have been refreshed to the 45-day window, and this update records two corrections to the 30-day report, per the changelog policy below. The 30-day report listed eleven providers with zero incidents; the correct number was twelve — Rackspace’s homepage monitor ran the full window on all four regions, was never paused, and recorded no incidents, and was left off the list by a hand-compilation error. It is now listed. The 30-day report also described OVHcloud’s longest outage as falling on August 28; it fell on September 8 (about 2.9 hours), with the August 28 episode at about 71 minutes; the totals were correct. From this refresh onward every published figure is generated by a scripted pipeline from the study’s incident records with the exclusions above applied as dated rules — the same script will produce the 60-day update and the final report.

How results will be published

August 8, 2026

Data collection started. Methodology published (this page).

September 14, 2026

30-day interim findings published — see the interim report.

September 23, 2026

Interim findings refreshed to 45 days. Correction: Rackspace added to the zero-incident list — it was omitted from the 30-day report in error (the correct count was twelve).

September 25, 2026

Cohort 2 monitoring began as a separate group (KnownHost, NixiHost, Krystal, Zume, ScalaHosting, Ultra Web Hosting, IONOS, Spaceship, Infomaniak). Excluded from this study; no Cohort 2 results published until its own methodology is.

September 28, 2026

Cohort 2 extended with 20i, AccuWebHosting, UltaHost and HostColor (homepage + robots.txt edge monitors, same interval, regions and quorum). Still excluded from this study; still unpublished.

Early November 2026

The full 90-Day Provider Reliability Report.

The interim findings, refreshed to 45 days, are out: read the interim report — two real Namecheap outages, a bad weekend for Dynadot, chronic slowness at Flywheel and WP Engine, ten spotless providers, and every exclusion dated.

Reports will include per-provider, per-region availability percentages, response-time medians and 95th percentiles, and every methodology adjustment made along the way, with dates. Raw aggregates will be available on request for anyone who wants to check our math. If a provider disputes a measurement, the contact page is open — we'll publish corrections with a changelog, the same policy as the rest of our methodology.