Blog · Operations

What 99.9% uptime actually means — and what actually breaks

By the HostingAlly team Published 27 July 2026 7 min read

Every host promises three nines. Almost nobody explains what the number means, what it excludes, or what the realistic failure modes on a hosting platform actually are. As a host, we think the mystique serves marketing more than customers — so here's the operational view, translated.

Start with the arithmetic: 99.9% uptime permits 43 minutes and 50 seconds of downtime per month. 99.99% permits 4 minutes 23 seconds. 100% doesn't exist and never has; any host claiming it is describing their aspiration, their measurement gaps, or their refund policy — not their infrastructure.

What actually takes websites down

In rough order of frequency on shared platforms: application-level failures (a plugin update that white-screens WordPress — the site is 'down' while the server is fine); resource exhaustion (a neighbouring account or your own traffic spike hitting PHP process limits); deployments and maintenance (kernel patches, PHP upgrades — the well-run version is measured in seconds of graceful restart); hardware failures (disks mostly, which is why RAID and real backups exist); network events (upstream provider issues, DDoS weather); and, rarest but most famous, whole-datacentre incidents.

The distribution matters because the marketing number only covers some of it. An uptime SLA measures whether the server answered — not whether your site worked. The plugin that broke your checkout doesn't appear in any host's downtime ledger. This is why daily backups and staging environments do more for your effective uptime than the difference between 99.9% and 99.95% ever will.

How to read an uptime guarantee

Three questions expose the substance of any SLA. First: measured by whom? A guarantee measured by the host's own monitoring, with maintenance windows excluded, is softer than one you can verify with an external monitor — set up free uptime monitoring on your own site in ten minutes and you own the ledger.

Second: what's the remedy? Typical SLA credits are a pro-rata refund of the downtime — literally pennies for an hour. The guarantee's real function is as a statement of engineering intent, not insurance. Judge hosts by their status-page history and how they communicate during incidents, not by the credit formula.

Third: what's excluded? Scheduled maintenance, 'emergency' maintenance, DDoS, upstream failures and force majeure are standard carve-outs. The narrower the exclusion list, the more the number means.

What we actually do about it

Our stack's uptime posture, concretely: NVMe RAID storage so single-disk failures are non-events; LiteSpeed serving cached pages so traffic spikes mostly never reach PHP; per-account resource isolation so a neighbour's bad day stays theirs; continuous external monitoring with alerting that pages a human; and daily backups with self-service restores so the application-level failures — the most common kind — are ten-minute fixes rather than outages.

And the honest limits: we do scheduled maintenance (announced, seconds-long, off-peak); we depend on upstream networks like everyone; and a sufficiently determined DDoS is weather, mitigated rather than prevented. We commit to 99.9% on every plan because it's the number we can stand behind across thousands of accounts — and we'd rather explain what it means than let it sit there as decoration.

Quick answers

How many minutes of downtime is 99.9% uptime?

About 43.8 minutes per month, or roughly 8 hours 46 minutes per year. 99.99% allows 4.4 minutes a month. The step between them costs far more to engineer than most small sites' downtime actually costs them — which is why 99.9% with fast, honest recovery is the sweet spot for shared hosting.

Do uptime guarantees pay out meaningful compensation?

Rarely — typical SLA credits are pro-rata refunds of the downtime period, which is pennies. Treat the SLA as an engineering promise to hold a host accountable to, and verify it yourself with a free external monitor rather than relying on the host's own dashboard.