Hosting providers advertise uptime figures like 99.9% or 99.99%. These numbers sound similar, but they mean very different amounts of allowed downtime. And an SLA (service level agreement) is usually a promise of credit, not a guarantee that your site stays online. Here’s how to read uptime claims, and how to get the availability you actually need.
Uptime percentages in real time
| Uptime | Downtime per month | Downtime per year |
|---|---|---|
| 99% | ~7.3 hours | ~3.65 days |
| 99.5% | ~3.6 hours | ~1.8 days |
| 99.9% (“three nines”) | ~43.8 minutes | ~8.8 hours |
| 99.95% | ~21.9 minutes | ~4.4 hours |
| 99.99% (“four nines”) | ~4.4 minutes | ~52.6 minutes |
| 99.999% | ~26 seconds | ~5.3 minutes |
Each extra “nine” is roughly ten times harder (and more expensive) to achieve.
What an SLA usually covers
- Network and host availability: the provider’s infrastructure, power, and network up to your VM.
- Service credits when monthly uptime falls below the promised level (for example a percentage of the monthly fee).
What SLAs typically exclude
- Scheduled maintenance (announced in advance).
- Problems inside your server: your software, configuration, crashed services, full disks, or a firewall mistake.
- Attacks such as DDoS, and events beyond the provider’s control.
- Third-party issues (upstream networks, DNS providers, registrars).
- Downtime you didn’t report within the claim window.
Read the provider’s SLA and terms for the exact definitions. See the VPS.DO legal policies.
Most downtime is self-inflicted
In practice, many outages on a VPS come from the server itself: an update that broke a service, a full disk, memory exhaustion, an expired certificate, or a configuration error. Prevent them:
- monitoring with alerts (uptime, disk, memory, certificate expiry). See Uptime Kuma and uptime monitoring tools;
- automatic security updates, but test major upgrades on staging;
- disk space alerts and log rotation. See VPS storage planning;
- services that restart automatically (
Restart=on-failurein systemd,restart: unless-stoppedin Docker); - certificate auto-renewal checks. See Let’s Encrypt.
Measure your own uptime
Don’t rely on the provider’s dashboard. Monitor from outside, from more than one location:
- HTTP checks for websites and APIs (status code and expected content).
- TCP or ping checks for game servers and other services.
- Alerts by email, Telegram, Slack or SMS.
Self-host Uptime Kuma on a different server or provider than the one it monitors, or use an external monitoring service.
Designing for higher availability
A single server, however reliable, can fail. If you need more than about 99.9%:
| Technique | What it protects against |
|---|---|
| Backups (off-site, tested) | Data loss, but restoring takes time |
| Warm standby server in another location | Server or data centre failure |
| Database replication | Database server failure. See database replication explained |
| Load balancer + 2+ app servers | Single app server failure. See Nginx load balancing |
| DNS failover / health-checked DNS | Routing users away from a failed site |
| CDN | Serves cached content when the origin has problems |
Recovery time and recovery point
Two numbers matter more than uptime percentages:
- RTO (recovery time objective): how long you can be down. That drives standby servers and automation.
- RPO (recovery point objective): how much data you can lose. That drives backup frequency and replication.
A blog may accept hours of RTO and a day of RPO. A shop’s checkout may need minutes and near-zero data loss.
Quick reference
| Term | Meaning |
|---|---|
| 99.9% | ~44 minutes downtime/month |
| 99.99% | ~4 minutes downtime/month |
| SLA | Credit if the provider misses its target |
| RTO / RPO | How long you can be down / how much data you can lose |
| Best practice | External monitoring + backups + redundancy where needed |
Related: when to upgrade your VPS and VPS vs cloud hosting.