The Uptime Study: 90-Day Final Report

The clean list — zero incidents in 90 days

• AWS Lightsail
• DigitalOcean
• Gandi
• Hostinger
• Name.com
• Pressable
• Rocket.net

Probes in the United States, Canada, Europe, and Asia-Pacific requested each provider's primary site every five minutes from August 8, 18:00 UTC to November 6, 18:00 UTC — 90 days, about 129,600 minutes per provider. A provider is marked down only when a majority of regions agree that requests failed outright (connection failures or an HTTP error status). "Degraded" means the site answered successfully but slowly, and it is reported separately because a slow page and an unreachable one are different failures. Degraded time is never counted as downtime anywhere in this report.

Two definitions matter more than they did at day 45, and we state them plainly. First, a check is recorded as degraded as soon as any one of the four regions crosses our three-second threshold, so a provider that is fast from three continents and slow from one accumulates degraded time; Migadu's and Flywheel's figures are mostly Asia-Pacific. Second, with four regions a 2–2 split on a failing request resolves to down. That rule touched exactly one episode in the study (Proton Mail's first 40 minutes on September 23); every other outage reported here was seen by at least three regions.

Every figure below was generated by the same scripted pipeline that produced the 45-day refresh, from the study's incident records, with every exclusion applied as a dated rule. Availability percentages are derived from hard downtime over the measured window; they exclude degraded time by definition.

Migadu is the new name at the top, and it earned the position in one episode. From October 25, 18:20 UTC until October 26, 14:05 UTC, every request to migadu.com from every region failed at the connection level — no HTTP status at all, just refused or dropped connections, for 1,229 minutes. At day 45 Migadu had two brief slow episodes and nothing else; one bad night put it at roughly 99.05% availability for the window, the lowest in the study. The two weeks after the outage were also slow from Asia-Pacific almost every day, which is why Migadu appears on both charts.

Proton Mail is the other new entry. Between September 23, 17:55 UTC and September 24, 08:49 UTC, proton.me returned HTTP 404 — a page-not-found error on its own homepage — to our United States, Canada and Europe probes, while Asia-Pacific continued to receive 200. Four episodes, 805 minutes in total, the longest about 9.3 hours overnight. We report it as the real HTTP failure it was: a visitor in three of our four regions would have been told the site did not exist. We also say what it is not: the mail service was never measured, only the marketing site, and nothing in our data speaks to whether anyone's email was affected.

Namecheap finished where the interim left it: two major outages, August 13 (about 9.3 hours) and September 1 (about 3.8 hours), both HTTP 503 from all four regions, 782 minutes in total, about 99.4% availability. Nothing further was recorded against it in the second half of the study. It remains the only provider with two major outages.

Dynadot's October was not as bad as its September weekend but it was busy: after one outage on August 27 and seven between September 19 and 21 (381 minutes), it recorded eight more short outages between October 8 and November 5, none longer than 34 minutes, for 560 minutes across 16 episodes — the most episodes of any provider. OVHcloud added a 115-minute episode on November 3 to its September run and finished at 535 minutes across six (about 99.6%). Hetzner's six brief episodes total 112 minutes, five of them in early September and one on October 30. DreamHost's single 18-minute outage on August 29 is unchanged. No other measured provider recorded any hard downtime in 90 days.

Flywheel is the study's defining slowness result from the first week to the last. Across 90 days it recorded 369 degraded episodes — about 166 hours in which getflywheel.com answered, but slowly, worst from our Asia-Pacific probes, with the longest single episode 372 minutes on September 29. It recorded no hard downtime at all. A conventional uptime report would score Flywheel 100%; by the measure its customers actually feel it is the worst performer in the field, and that contrast is the most useful thing this study has produced.

Two providers that were nowhere near the top at day 45 are now second and third. Migadu logged about 119 hours across 170 episodes: a 15-hour slow stretch on October 5–6, then slow responses most days after its October 25 outage, almost all of it from Asia-Pacific. Scaleway logged about 109 hours across 172 episodes; it had eleven episodes before October, then slow responses on most days from October 9 to the end of the window, the longest 373 minutes on October 29.

Behind those three the picture is steadier. Nexcess logged 58 episodes (about 27.5 hours, measured on its four-region edge check, more than half of it in one 656-minute episode on September 25). WP Engine, Flywheel's sibling brand, logged 74 episodes (about 27 hours) spread evenly across the study. Hover's 43 episodes (about 20 hours) were concentrated in late September and have since settled. Proton Mail's 40 slow episodes (about 12 hours) fall mostly on October 27–31, separate from its September outage. DreamHost (35 episodes, 8.6 hours), A2 Hosting (17, 4.7 hours, concentrated August 18–21) and MXroute (10, 3.5 hours, all after September 21) round out the top ten. Fifteen further providers logged degraded time; the largest of those is Namecheap at just under two hours, and eight of them logged less than an hour across the whole study.

Seven providers went the full 90 days with nothing recorded against them — no downtime and no degraded episodes: AWS Lightsail, DigitalOcean, Gandi, Hostinger, Name.com, Pressable, and Rocket.net. That is two cloud platforms, two registrars, one shared host and two managed WordPress hosts.

The list shrank from twelve at day 30 and ten at day 45, and the three names that fell off deserve the context: SiteGround logged a single 11-minute slow episode on November 3; Google Workspace two short ones totaling 27 minutes; Rackspace two in the final three days totaling 34 minutes. None recorded a second of hard downtime. The near-clean group is worth naming in full, because the difference between it and the clean list is a handful of minutes: Kinsta (one 12-minute episode), InMotion Hosting (one of 18 minutes, on its edge check), Hivelocity (23 minutes), Cloudflare Registrar (46 minutes), Liquid Web (35 minutes), Fastmail (62 minutes), Zoho Mail (68 minutes) and Linode's edge check (59 minutes) all finished with no hard downtime and under 70 slow minutes.

Three of the 37 providers in the frozen cohort do not permit independent automated measurement. Vultr blocked our probes from day one, including robots.txt. Bluehost and Cloudways were measurable from our United States probe until August 31, then blocked that address too, and were dropped on September 14 rather than guessed at. None of the three has a number in this report, and we would treat any uptime figure published for them by a third party with the same scepticism.

Microsoft 365 was measurable and has no number either, for a different reason. Its homepage answers every region at roughly 3.0 to 3.2 seconds, oscillating around our own three-second threshold, so its monitor spent the study flipping in and out of "degraded" while returning HTTP 200 throughout. We flagged this at day 37 and said it would be tuned; it was not, and six back-to-back artifact incidents run from September 1 to the end of the window. The honest treatment is the one the interim applied: the data is flagged, not clean, and Microsoft 365 appears on no chart. It recorded no hard downtime.

InMotion Hosting, Namecheap, Nexcess and Linode are measured on their globally-served robots.txt rather than their homepages, because those homepages block non-residential traffic; the methodology page records when and why. Their availability figures are real, but a clean edge check is a weaker statement than a clean homepage, so none of the four is awarded a clean sheet.

The hard-downtime table gained two major outages (Migadu, Proton Mail) and a provider — Migadu — that was not on either chart at day 45. Dynadot roughly doubled its episode count. OVHcloud added one episode. Hetzner added one. Namecheap and DreamHost did not move.

The degraded table changed shape: Flywheel nearly doubled its minutes but kept its position; Migadu and Scaleway rose from outside the top ten to second and third; WP Engine, Hover and Nexcess fell in rank without falling in time. Three providers left the clean list for a combined 72 slow minutes, none of them downtime.

The study also lost about five and a half hours of measurement that we had not disclosed until now, described in the next section. No published figure changed as a result; the gap produced no incidents, and we report it because the methodology says every measurement problem is disclosed with a date.

The exclusions are the ones disclosed on the methodology page and applied in the 45-day refresh, and they have not changed: the five US-only monitors' ten-day false downtime from August 31 (a bot-wall's 403s, every response under 100 ms, all five sites fine from residential connections); Namecheap's edge check bot-blocked from September 8, 18:10 to September 9, 07:31 UTC; a 40-minute false alarm on August 8; the day-one reputation block that paused Linode's and Vultr's homepage monitors; and Microsoft 365's threshold artifact. Eleven incident records were removed from this window under those rules, each logged with its reason in the reconciliation file behind this report.

Two measurement gaps were not on the methodology page and are now. On October 2 the scheduler that dispatches checks stalled from about 16:00 to 21:30 UTC across all four regions; the probes were healthy and the few checks that ran returned normal results, so no false incidents were created, but roughly five and a half hours of the window have far fewer measurements than the rest. On October 3 at 13:51 UTC one five-minute dispatch cycle was lost during the repair. Any outage that began and ended entirely inside those gaps would have been missed; we have no evidence one did.

Two promises were not kept. The methodology page said reports would include per-provider, per-region response-time medians and 95th percentiles. The consolidated record this report is built from stores per-region times inside each check's evidence rather than in a form we can aggregate honestly across 900,000 checks on the current database, so those percentiles are held for the open-data release rather than estimated. And the 60-day update scheduled for around October 8 was never published; the pipeline was ready and the step was simply not run. Both are our failures, not the data's, and we would rather list them here than let the schedule table imply otherwise.

The 34 monitors keep running. The study's frozen cohort was a commitment about which providers would be compared over a fixed window, not a commitment to stop measuring, and the provider profiles on this site will keep citing the figures from this report until a successor window is published with its own methodology.

Cohort 2 — the thirteen providers added to the site after the roster was frozen — has been monitored as a separate group since September 25 and nothing from it has been or will be published until the quorum change that treats blocked responses as invalid rather than down is in place and its own methodology page is out. The raw incident records behind this report, the exclusion rules as data, and the reconciliation of every figure here against them are available on request through the contact page, and the full exports will be added to the open-data hub.

If a provider disputes a measurement, the contact page is open. Corrections are published with a changelog, as the 45-day refresh demonstrated when it added Rackspace to the clean list and moved OVHcloud's longest outage to the right date.