99.9% uptime: what the number buys and what actually breaks

Roughly in order of how often we see them on shared platforms. Application failures come first: a plugin update white-screens WordPress and the site is down while the server is perfectly healthy. Then resource exhaustion, where your own traffic spike or a neighbouring account runs into PHP process limits. Then deployments and maintenance such as kernel patches and PHP upgrades, which done well are seconds of graceful restart. Then hardware, mostly disks, which is why RAID and real backups exist. Then network events, meaning upstream provider trouble and DDoS weather. Last and most famous, whole-datacentre incidents.

That order matters because the advertised number only covers part of it. An uptime SLA records whether the server answered, not whether your site worked. The plugin that broke your checkout appears in nobody's downtime ledger. Which is why daily backups and a staging copy do more for the uptime your visitors experience than the gap between 99.9% and 99.95% ever could.

Concretely, here is our posture. NVMe RAID storage, so a single failed disk is a non-event. LiteSpeed serving cached pages, so most traffic spikes never touch PHP. Per-account resource isolation, so a neighbour's bad afternoon stays theirs. Continuous external monitoring with alerts that wake a human. Daily backups with self-service restores, so the commonest failure of all, the application-level kind, becomes a ten-minute fix instead of an outage.

And the limits, stated plainly. We do scheduled maintenance, announced, off-peak and measured in seconds. We depend on upstream networks like everyone else. A determined DDoS is weather we mitigate rather than prevent. We commit to 99.9% on every plan because that is the figure we can hold across thousands of accounts, and we would rather explain it than leave it sitting on the page as decoration.