SLA Percentages Explained: What Five Nines Really Means

"We guarantee 99.9% uptime." Sounds impressive, but what does it actually mean? The difference between 99.9% and 99.99% is larger than it appears. Here's what those percentages translate to in real downtime.

Uptime Calculator Calculate downtime from any SLA percentage

The Uptime Table

Uptime %	Name	Downtime/Year	Downtime/Month	Downtime/Week
99%	Two nines	3.65 days	7.3 hours	1.68 hours
99.5%	Two and a half	1.83 days	3.65 hours	50.4 min
99.9%	Three nines	8.76 hours	43.8 min	10.1 min
99.95%	Three and a half	4.38 hours	21.9 min	5.04 min
99.99%	Four nines	52.6 min	4.38 min	1.01 min
99.999%	Five nines	5.26 min	26.3 sec	6.05 sec
99.9999%	Six nines	31.5 sec	2.63 sec	0.6 sec

Why Each Nine Gets Exponentially Harder

Moving from 99% to 99.9% cuts your allowed downtime by 90%. Moving from 99.9% to 99.99% cuts it by another 90%. Each additional nine requires:

• More redundant systems
• Faster failover mechanisms
• Better monitoring and alerting
• More rigorous change management
• Higher quality components
• More expensive infrastructure

The cost often increases exponentially too. Five nines might cost 10x more than four nines.

Calculating Composite Availability

When systems depend on each other, you multiply their availability:

Total = System A × System B × System C

Example: An application requires a web server (99.9%), database (99.95%), and network (99.99%):

0.999 × 0.9995 × 0.9999 = 0.9984 = 99.84%

Your 99.9% web server just became a 99.84% application—over 14 hours of downtime per year.

The Power of Redundancy

Redundant systems with independent failures multiply availability differently:

Unavailability = (1 - A)^n
Availability = 1 - Unavailability

Where n is the number of redundant systems. Example: Two 99% servers in active-active:

Unavailability = (1 - 0.99)^2 = 0.0001
Availability = 99.99%

Two 99% systems become 99.99% together—if their failures are truly independent.

SLA Fine Print to Watch

Not all SLAs are equal. Watch for these variations:

• Measurement period: Monthly SLAs reset each month. An outage on the 1st affects only that month.
• Exclusions: "Scheduled maintenance" is often excluded from downtime calculations.
• Degraded performance: Is 50% packet loss considered "up"?
• Measurement method: Who measures? From where? How often?
• Credits vs. refunds: Credits for future service aren't the same as money back.
• Caps: "Up to 30% credit" means you'll never get more than that.

Real-World SLA Examples

Service	Typical SLA	Annual Downtime
Budget hosting	99.9%	8.76 hours
AWS EC2	99.99%	52.6 minutes
Azure (single region)	99.9-99.99%	Varies by service
Enterprise ISP	99.95%	4.38 hours
Tier III data center	99.982%	1.6 hours
Tier IV data center	99.995%	26 minutes

What Uptime Do You Actually Need?

Consider the cost of downtime versus the cost of higher availability:

• Personal blog: 99% is fine (3.6 days/year of downtime)
• Small business site: 99.9% is reasonable (8.7 hours/year)
• E-commerce: 99.95% minimum (4.4 hours/year)
• Financial services: 99.99%+ (under an hour/year)
• Emergency services: 99.999% (5 minutes/year)

Calculate your cost per hour of downtime, then compare it to the cost of higher availability infrastructure.

MTBF and MTTR

Two related metrics that affect availability:

• MTBF (Mean Time Between Failures): Average time a system runs before failing
• MTTR (Mean Time To Repair): Average time to restore service after failure

Availability = MTBF / (MTBF + MTTR)

You can improve availability by either increasing MTBF (better components, redundancy) or decreasing MTTR (faster detection, automated recovery, better runbooks).

The Five Nines Reality Check

True five nines (99.999%) allows only 5.26 minutes of downtime per year. This requires:

• Multiple redundant data centers
• Automatic failover in seconds
• Zero-downtime deployments
• 24/7/365 operations teams
• Extreme change management discipline
• Significant investment in testing

Very few organizations achieve true five nines. Many that claim it exclude planned maintenance, certain failure types, or measure differently than you'd expect.

Practical Takeaway

For most businesses, obsessing over five nines is counterproductive. Instead:

1. Calculate your actual cost of downtime per hour
2. Determine what uptime level is economically rational
3. Design for that level with appropriate redundancy
4. Focus on reducing MTTR—it's often cheaper than improving MTBF
5. Read SLAs carefully and understand what's actually guaranteed