99.9% uptime: what the number allows and what really breaks

Ordered roughly by how often we meet them on shared platforms. Application faults come first: a plugin update white-screens WordPress and the site is dark while the server beneath it hums along untroubled. Then resource exhaustion, where your own surge in traffic or a neighbouring account runs into PHP process limits. Then planned work such as kernel patches and PHP upgrades, which done properly cost seconds of graceful restart. Then hardware, usually disks, which is what RAID and real backups exist for. Then events on the network, by which we mean upstream carrier trouble and DDoS. Last and best known, whole-datacentre incidents.

The order matters because the advertised figure covers only part of it. What an uptime SLA records is whether the server answered, not whether the site worked. No downtime column anywhere records the plugin that broke your checkout. Which is why daily backups and a staging environment do more for the uptime your readers actually feel than the gap between 99.9% and 99.95% ever will.

In concrete terms, this is the arrangement. NVMe RAID storage, so one dead disk changes nothing. LiteSpeed serving cached pages, which keeps most traffic spikes away from PHP entirely. Per-account resource isolation, so a neighbour's difficult afternoon never becomes yours. Continuous external monitoring wired to alerts that wake a real person. Nightly backups with self-service restores, which turn the commonest failure class of all, the application kind, from an outage into a ten-minute rollback.

And the limits, said plainly. Scheduled maintenance happens here, announced in advance, off-peak, and counted in seconds. We depend on upstream networks as every other host does. A determined DDoS is weather: we soak it up and blunt it, but nobody abolishes it. We commit to 99.9% on every plan because that is the level we can hold across thousands of accounts, and we would rather explain the number than leave it on the page as decoration.