Every hosting provider advertises uptime. “99.9% uptime guaranteed.” “99.95% availability.” “Five nines.” The numbers feel similar until you convert them to actual downtime, and then the differences become significant.
The math first, then what it actually takes to achieve each tier.
The Uptime Math
| SLA | Annual Downtime | Monthly Downtime |
|---|---|---|
| 99% | 87.6 hours | 7.3 hours |
| 99.5% | 43.8 hours | 3.65 hours |
| 99.9% | 8.76 hours | 43.8 minutes |
| 99.95% | 4.38 hours | 21.9 minutes |
| 99.99% | 52.6 minutes | 4.38 minutes |
| 99.999% | 5.26 minutes | 26.3 seconds |
The gap between 99.9% (“three nines”) and 99.99% (“four nines”) is the difference between 8.76 hours and 52 minutes of annual downtime. For a business with significant online revenue, that gap is the difference between minor inconvenience and meaningful business impact.
What 99.9% Actually Requires
99.9% uptime — the most common SLA offered by mid-tier hosting providers — allows for roughly 9 hours of downtime per year. This sounds like a lot until you consider how quickly downtime accumulates:
- A planned maintenance window of 2 hours
- A failed deployment that requires rollback: 20 minutes
- An ISP outage: 45 minutes
- A disk failure and replace cycle: 2 hours
- A database issue requiring intervention: 1 hour
That’s almost 6 hours in plausible, common events — without any major incidents. Achieving 99.9% requires planning and discipline; it’s not achievable through luck.
The infrastructure that makes 99.9% achievable: a single server with redundant hardware (RAID storage, redundant power supplies), a monitoring system that catches failures quickly, and documented runbooks for common failure scenarios. Not multi-site redundancy, not Kubernetes, not sophisticated failover — just well-configured hardware, good monitoring, and operational discipline.
99.9% for most workloads is achievable and appropriate. It’s the tier where the operational investment is proportional to the benefit.
The Jump to 99.99%
Going from 99.9% to 99.99% is an order-of-magnitude reliability increase — from 8.76 hours to 52 minutes of annual downtime. The architectural changes required are significant:
Eliminate single points of failure. Every component that can fail and cause downtime needs a redundant counterpart. Load balancers, database primaries, application servers — all of these need standby instances that can take over automatically.
Automated failover. At 99.99%, there’s no room for “someone noticed and manually failed over.” Failover must be automatic and fast. This requires health checking at every layer, routing changes that propagate in seconds, and standby instances that are warm and ready to serve traffic.
Multi-AZ or multi-site deployment. A single data center, however well-run, has tail risks — power events, network events, physical issues — that make it impossible to guarantee 99.99% without geographic redundancy.
Maintenance without downtime. At 99.99%, planned maintenance windows can’t take the service down. Upgrades, patches, and configuration changes must be applied with zero-downtime procedures (rolling deployments, blue-green switches, live database migrations).
The cost of 99.99% infrastructure is roughly double the cost of 99.9% infrastructure, because everything that matters needs to exist in duplicate.
What’s Not Covered by Uptime SLAs
Uptime SLAs typically cover the service being reachable. They don’t cover:
Performance degradation. A service that responds in 30 seconds is technically “up” but operationally unusable. SLAs focused purely on uptime don’t capture this. Look for SLAs that include response time commitments alongside availability commitments.
Planned maintenance. Most uptime SLAs exclude planned maintenance windows from the calculation. A provider that does 4 hours of planned maintenance per month isn’t providing 99.99% from the user’s perspective, even if the SLA technically allows it.
Third-party dependencies. If your application depends on a third-party payment processor, email service, or CDN, their downtime affects your users but is outside your hosting provider’s SLA.
Database availability vs. application availability. Some SLAs measure web server availability, not database availability. If the database goes down and the web server continues responding with error pages, that may count as “up” in the SLA while being completely unavailable to users.
When evaluating SLA language, ask specifically: what does “uptime” measure? What is excluded? What is the compensation structure when the SLA is violated?
The Compensation Question
Most hosting SLAs include service credits for downtime that violates the SLA terms. Service credits are typically calculated as a percentage of the monthly bill — often 10-25% per hour of excess downtime.
For businesses where downtime causes significant revenue loss or operational disruption, service credits rarely reflect the actual business impact. A 10% monthly credit for 4 hours of downtime doesn’t compensate for 4 hours of lost e-commerce revenue.
This isn’t a reason to avoid SLAs — it’s context for evaluating them. Service credits are a signal of the provider’s confidence in their reliability, not a complete risk mitigation strategy. The actual risk mitigation is building your application on infrastructure that doesn’t go down for 4 hours, not collecting credits when it does.
Choosing the Right Tier for Your Business
The uptime tier decision should follow from business requirements:
What’s the actual cost of downtime for your specific business? An e-commerce site loses revenue proportional to traffic and conversion rate. A B2B SaaS disrupts customer operations. An internal tool inconveniences employees. The cost-benefit analysis requires a real number, not a gut feel.
When does downtime happen? Nighttime downtime that affects no active users has a different business impact than peak-hour downtime. Many applications can tolerate the maintenance windows that 99.9% allows if they’re scheduled outside business hours.
What’s the cost increment for higher availability? If 99.99% infrastructure costs twice as much as 99.9% infrastructure, but the expected business impact of the additional downtime is minimal, the premium isn’t justified.
For most small and mid-size businesses, 99.9% is the appropriate target — achievable at reasonable cost, appropriate for most workload requirements. The investment in 99.99% makes sense for applications where downtime has clear, measurable business impact that justifies the cost.
Our managed hosting service operates with explicit uptime commitments tied to the specific infrastructure configuration. Related: if your uptime requirements connect to a broader disaster recovery strategy, our cloud migration and cost optimization practice includes DR architecture planning as part of the infrastructure design.