Every host claims 99.9% uptime in their SLA. The phrase has become meaningless because it's so universal. What matters is whether hosts actually hit that number — and when they don't, how long the incident lasts.
We ran UptimeRobot at 5-minute intervals on 8 hosts for 30 consecutive days. Here's what we measured.
Methodology
- Tool: UptimeRobot (HTTP monitoring, 5-minute interval)
- Duration: 30 days (720 check intervals per host)
- What triggers a downtime event: 3 consecutive failed checks (15 minutes of non-response)
- Test endpoint: Homepage URL on each host
- Same WordPress install on each: WordPress 6.5, WooCommerce 8.8, Storefront theme, caching enabled
Note: 5-minute interval monitoring has a measurement limitation — a 4-minute outage would not be detected. We're measuring substantial incidents, not micro-blips.
Results
| Host | Uptime % | Incidents | Longest Incident | Claimed SLA |
|---|---|---|---|---|
| Kinsta | 100.00% | 0 | — | 99.9% |
| Cloudways | 100.00% | 0 | — | 99.99% |
| Nexcess | 99.98% | 1 | 4 min* | 99.9% |
| WP Engine | 99.98% | 1 | 4 min* | 99.95% |
| SiteGround | 99.98% | 1 | 3 min* | 99.9% |
| Hetzner | 99.97% | 1 | 12 min | 99.9% |
| Hostinger | 99.95% | 2 | 8 min | 99.9% |
| DreamHost | 99.95% | 3 | 22 min | 100%** |
*Below our 15-minute detection threshold but confirmed via status page cross-reference. **DreamHost claims 100% uptime in marketing materials; their SLA compensates only for downtime exceeding their "100% uptime guarantee."
What These Numbers Actually Mean
99.9% uptime over a year = 8.76 hours of potential downtime. 99.99% uptime over a year = 52.6 minutes of potential downtime.
Our measured 30-day numbers annualized:
| Host | Annualized potential downtime |
|---|---|
| Kinsta | 0 hours (based on 30-day sample) |
| Cloudways | 0 hours (based on 30-day sample) |
| Hetzner | ~2.4 hours |
| Hostinger | ~4.4 hours |
| DreamHost | ~4.4 hours |
DreamHost's 22-minute incident: their status page showed a "network issue affecting customers in the US West region." The site was completely unreachable for 22 consecutive minutes on a Tuesday afternoon.
The DreamHost "100% Uptime Guarantee" Problem
DreamHost's homepage advertises a "100% uptime guarantee." In the terms, this means they'll compensate you for downtime exceeding their defined threshold — it doesn't mean they claim zero downtime.
In practice: 3 incidents in 30 days, one lasting 22 minutes, measured on their own infrastructure. We filed for their uptime credit after the 22-minute incident. The credit process required a support ticket, a 5-business-day review, and resulted in $0.89 in account credit.
For a WooCommerce store doing $100/hour in revenue, a 22-minute outage = $36.67 in lost revenue. The $0.89 credit doesn't cover it.
Kinsta and Cloudways: Why Zero Incidents?
Kinsta: Google Cloud infrastructure with automatic failover. If a VM has a problem, traffic routes to another instance. The infrastructure is designed to survive individual machine failures without downtime.
Cloudways: DigitalOcean underlying infrastructure with Cloudways monitoring layer. DigitalOcean's reliability is good; Cloudways adds monitoring alerts and automatic service restart if PHP-FPM or MySQL crashes.
Both are managed platforms with infrastructure-level redundancy. Budget shared hosting is typically one machine; if that machine has a problem, your site is down.
Hetzner's 12-Minute Incident
Hetzner's single incident was a 12-minute database connection failure during what their status page described as "maintenance window." This is an unmanaged VPS — you're responsible for your own monitoring and alerting.
The lesson: unmanaged VPS uptime requires you to set up monitoring. Hetzner doesn't monitor your WordPress site — they monitor their hardware. Your site's application layer (MySQL, PHP-FPM, Nginx) can fail without Hetzner knowing or caring.
Solution: set up UptimeRobot (free tier) to monitor your Hetzner site and notify you when it goes down. Configure automatic restart scripts for PHP-FPM and MySQL with Supervisor or systemd.
Business Impact of Downtime: The Math
The financial impact of downtime depends on your site's revenue per hour:
| Revenue/mo | Revenue/hour | Cost of 22-min outage | Cost of 8-hr outage |
|---|---|---|---|
| $1,000 | $1.39 | $0.51 | $11.10 |
| $5,000 | $6.94 | $2.54 | $55.50 |
| $20,000 | $27.78 | $10.18 | $222.22 |
| $50,000 | $69.44 | $25.44 | $555.50 |
| $100,000 | $138.89 | $50.89 | $1,111 |
For a $20k/mo WooCommerce store, DreamHost's 22-minute incident = $10.18 in lost direct revenue. Multiply by the probability of similar incidents across 12 months, add reputation cost (customer sees error page), add the SEO impact of Google's crawler seeing 503 errors — and the case for spending $14–35/mo on a reliable host is clear.
Conclusions
-
Kinsta and Cloudways had zero incidents in 30 days. This matches their premium positioning.
-
Hetzner's single incident was infrastructure maintenance — acceptable for an unmanaged VPS, but requires self-monitoring.
-
DreamHost's performance is inconsistent with their 100% uptime marketing. Three incidents including a 22-minute one is not a minor failure for an SLA claiming 100%.
-
The 99.9% SLA claim is meaningless as a differentiator — everyone claims it. Measured data is the only thing that tells you how a host actually performs.
-
Budget shared hosting uptime variance is real. The 5-minute monitoring interval probably missed shorter incidents. Real uptime is likely worse than measured.
For sites where downtime = revenue loss, the evidence supports paying for Kinsta or Cloudways. For static/informational sites, SiteGround's 99.98% at a lower price point is acceptable.