99.9% uptime: what the figure permits and what really fails

Listed roughly by how often we meet them on shared platforms. Application faults lead: a plugin update white-screens WordPress and the site is dark while the server underneath hums along fine. Next comes resource exhaustion, where your own traffic surge or a neighbouring account collides with PHP process limits. Then planned work such as kernel patches and PHP upgrades, which done well cost seconds of graceful restart. Then hardware, usually disks, which is what RAID and real backups are for. Then network events, meaning upstream carrier trouble and DDoS weather. Last and most famous, whole-datacentre incidents.

The order matters because the advertised figure covers only a slice of it. An uptime SLA records whether the server responded, not whether your site worked. The plugin that broke your checkout registers in no one's downtime column. Which is why daily backups and a staging environment do more for the uptime your visitors actually feel than the distance between 99.9% and 99.95% ever will.

In concrete terms, here is the setup. NVMe RAID storage, so a single dead disk changes nothing. LiteSpeed answering cached pages, so most traffic spikes never reach PHP at all. Per-account resource isolation, so a neighbour's rough afternoon never becomes yours. Continuous external monitoring wired to alerts that wake an actual human. Daily backups with self-service restores, turning the most frequent failure class of all, the application kind, from an outage into a ten-minute rollback.

And the limits, stated plainly. We run scheduled maintenance, announced, off-peak and measured in seconds. We depend on upstream networks like every other host. A determined DDoS is weather we absorb and mitigate rather than something we can abolish. We commit to 99.9% on every plan because that is the level we can sustain across thousands of accounts, and we would rather walk you through the number than leave it on the page as decoration.