The Uptime Study: 45-Day Interim Findings

The clean list — zero incidents in 45 days

• AWS Lightsail
• DigitalOcean
• Gandi
• Google Workspace
• Hostinger
• Name.com
• Pressable
• Rackspace
• Rocket.net
• SiteGround

Probes in the United States, Canada, Europe, and Asia-Pacific request each provider's site every five minutes. A provider is only marked down when a majority of regions agree — a single flaky network path never counts. "Down" means requests failed outright (connection failures or HTTP error status); "degraded" means the site answered successfully but slowly. We report the two separately, because a slow page and an unreachable one are different failures.

The observation window is August 8, 18:00 UTC through September 22, 2026 — about 64,800 minutes per provider. The full methodology, including every mid-study adjustment with dates, lives on the uptime-study page linked below. As of this refresh every figure is generated by a scripted pipeline from the study's incident records, with the exclusions applied as dated rules, rather than compiled by hand.

Namecheap is the only provider in the study with major multi-region outages — two of them. On August 13 its site returned HTTP 503 from all four regions from 12:33 to 21:49 UTC, roughly 9.3 hours. On September 1 the same signature repeated from 07:19 to 11:05 UTC, another 3.8 hours. Combined that is about 13 hours of hard downtime in 45 days — roughly 98.8% availability — and still more downtime than any other provider we measured, though the gap has narrowed since the 30-day report.

The rest of the list has grown. Dynadot had a single 29-minute outage on August 27 and nothing else for three weeks; then, between the early hours of September 19 and the morning of September 21, it went down seven more times — 90, 28, 39, 59, 41, 23 and 72 minutes — for 381 minutes in total. None was long enough to count as a major outage, but together they put Dynadot third on the list, and its separate four-region robots.txt check confirmed two of the September 21 episodes independently. OVHcloud was unreachable for about 7 hours across five separate episodes (connection failures from every region; the longest, about 2.9 hours, on September 8; the newest on September 17). Hetzner logged five brief episodes totaling about 89 minutes, all in the first half of September, and DreamHost a single 18-minute one on August 29. No other provider in the study recorded any hard downtime.

Flywheel remains the study's defining slowness story: 209 degraded episodes in 45 days — a near-daily pattern, worst from our Asia-Pacific probes — adding up to roughly 87 hours in which its site answered but slowly. Nothing else in the field looks like it.

The number two chronic performer is still WP Engine, Flywheel's premium-priced sibling brand: 46 degraded episodes totaling about 19 hours, unchanged since the 30-day report, including an August 21–22 cluster of repeated 44–73-minute episodes. For hosts positioned and priced on performance, the pairing remains notable — and it echoes what our renewal-price index shows about paying premium rates.

The mover is Hover. At day 37 it had 8 degraded episodes and about 3 hours; it now has 25 and about 13 hours, with 17 of those episodes and most of the time concentrated on September 21–22, the longest running 73–75 minutes. Behind those three: Nexcess logged 32 degraded episodes (~9 hours, measured on its four-region edge check), A2 Hosting 14 (concentrated August 18–21), DreamHost 14, Scaleway 11, and MXroute — spotless at day 37 — six episodes since September 21. All are patterns worth watching through the final report; none is in Flywheel's class.

Ten providers have gone the full 45 days with zero recorded incidents of any kind — no downtime, no degraded episodes: AWS Lightsail, DigitalOcean, Gandi, Google Workspace, Hostinger, Name.com, Pressable, Rackspace, Rocket.net, and SiteGround.

Two providers that were spotless at day 37 have since picked up a blemish: Cloudflare Registrar logged a single 12-minute degraded episode, and MXroute the six noted above. A further group remains near-spotless: Hivelocity, Kinsta and Liquid Web have each logged exactly one brief degraded episode of 11–12 minutes across the entire window, Migadu two totaling 22 minutes, and Fastmail two totaling 34 minutes.

Our methodology page promises corrections with a changelog, so here they are. First and most important: the 30-day report said eleven providers had zero incidents. The correct number was twelve. Rackspace's homepage monitor ran the full window on all four regions, was never paused or in maintenance, and recorded no incidents of any kind; it was left off the published list by a hand-compilation error, not by the data. It is on the list above, where it belonged all along.

Second, a smaller one: the 30-day report described OVHcloud's longest outage as falling on August 28. It fell on September 8 and lasted about 2.9 hours; the August 28 episode was about 71 minutes. The totals were correct.

This refresh is the first produced by a scripted pipeline rather than by hand. Every figure is generated from the study's incident records with the exclusions applied as dated rules, and the same script will produce the 60-day update and the final report. The error above is exactly the class of mistake it exists to prevent.

Publishing bad data would be worse than publishing none, so here is everything we removed from the statistics, with dates. All of it is also disclosed on the methodology page, and the underlying probe evidence is retained.

First: from August 31, 19:15 UTC, the five providers measurable only from our US probe (Bluehost, Cloudways, InMotion Hosting, Namecheap, Nexcess) began returning HTTP 403 to that probe — their bot-mitigation had flagged its network address. Being single-region monitors, no other region could outvote the block, and they recorded ten days of false 'downtime' before our September 10 audit caught it. Every request in that window returned 403 in under 100 ms — a bot-wall's signature, not an outage's — and all five sites answered normally from ordinary residential connections throughout. The window is excluded for those five monitors; availability measurement for InMotion, Namecheap, and Nexcess continued unbroken on their separate four-region checks.

Second: Namecheap's four-region check itself was bot-blocked for one window — September 8, 18:10 to September 9, 07:31 UTC, all four regions returning 403 in tens of milliseconds. Excluded on the same evidence standard. The two real Namecheap outages reported above show the opposite signature: HTTP 503 service errors, the same code its edge served during its verified August 13 incident.

Third, smaller items: a 40-minute false alarm at study start on August 8 (the same five providers' bot-walls rejecting non-US probes before we narrowed those monitors to US-only — the config change disclosed on day one); and Microsoft 365's monitor, which spent much of September nominally 'degraded' because its response times oscillate right around our 3.0-second threshold while returning HTTP 200 from every region — a threshold artifact we've flagged for tuning, and in any case degraded time is never counted as downtime.

Finally, a roster change: Bluehost and Cloudways now block our probes entirely — homepage and robots.txt alike, from every region and every address we measure from — and as of September 14 they are dropped from the study rather than guessed at. That itself is a finding: of 37 providers, three (Vultr since day one, now Bluehost and Cloudways) do not permit independent automated measurement at all. The study continues with 34.