What Is 99.9% Uptime? The SLA Nines Explained
99.9% uptime sounds reliable until you realize it allows 8 hours and 46 minutes of downtime per year. Here's what each SLA tier actually means, how to calculate allowed downtime, and which target is right for your service.
99.9% uptime means your service can be down for up to 8 hours and 46 minutes per year while still meeting its SLA. Most SaaS products target this tier. Financial infrastructure targets 99.999%. The difference between the two is 8 hours and 41 minutes of allowed downtime annually.
The "nines" shorthand refers to the number of 9s in the uptime percentage: 99.9% is "three nines," 99.99% is "four nines," 99.999% is "five nines."
The Uptime Nines Table
| Uptime % | Common Name | Downtime / Year | Downtime / Month | Downtime / Week |
|---|---|---|---|---|
| 99% | Two nines | 3 days 15 hrs 36 min | 7 hrs 18 min | 1 hr 41 min |
| 99.9% | Three nines | 8 hrs 45 min 36 sec | 43 min 50 sec | 10 min 5 sec |
| 99.95% | Three and a half nines | 4 hrs 22 min 48 sec | 21 min 55 sec | 5 min 2 sec |
| 99.99% | Four nines | 52 min 33.6 sec | 4 min 22 sec | 1 min 5 sec |
| 99.999% | Five nines | 5 min 15.4 sec | 26.3 sec | 6 sec |
| 99.9999% | Six nines | 31.5 sec | 2.6 sec | 0.6 sec |
How to Calculate Allowed Downtime
The formula is straightforward:
Allowed downtime = Total time × (1 - Uptime %)
For 99.9% uptime over one year:
8,760 hours × (1 - 0.999) = 8,760 × 0.001 = 8.76 hours
For 99.9% uptime per month (730 hours):
730 × 0.001 = 0.73 hours = 43.8 minutes
The key number for monthly SLA reporting: 43 minutes and 50 seconds is your budget at 99.9%.
What Each Tier Actually Requires
99% (Two Nines)
Three and a half days of allowed downtime per year. Acceptable for development environments, internal tools, and non-revenue-generating services. Any production service with paying customers should target higher.
99.9% (Three Nines)
The baseline for most SaaS products. Under 9 hours of annual downtime. Achievable with standard cloud infrastructure, automated deployments, and basic monitoring. Most startup SLAs promise this tier because it's realistic to deliver without dedicated SRE headcount.
99.95% (Three and a Half Nines)
About 4.5 hours of annual downtime. Common in mid-market B2B contracts where customers are on production systems but the service isn't life-critical. The half-nine step requires redundant infrastructure and faster incident response.
99.99% (Four Nines)
52 minutes of allowed downtime per year. This is where engineering investment escalates sharply. Four nines requires:
- Multi-region redundancy with automatic failover
- Zero-downtime deployments
- Sub-minute incident detection (1-minute check intervals are the maximum useful here)
- Dedicated on-call rotation
- Incident playbooks tested regularly
99.999% (Five Nines)
5 minutes and 15 seconds per year. Reserved for financial systems, healthcare infrastructure, telecommunications, and enterprise platforms where downtime has legal or safety consequences. Requires active-active multi-region architecture, hardware redundancy, and real-time monitoring with sub-30-second detection.
Why the Jump from 99.9% to 99.99% Is Harder Than It Looks
Going from two nines to three nines is mostly a discipline problem: better deployments, better monitoring, faster incident response. Going from three to four nines is an architecture problem.
At 99.99%, you can tolerate roughly one 5-minute outage per month before breaching your SLA. A single bad deployment, database restart, or certificate expiry can consume your entire annual budget.
The engineering cost compounds at each tier. A 2024 survey by Atlassian found that achieving four nines costs roughly 3-5x more in infrastructure and engineering time than three nines, even when the underlying application architecture is similar.
SLA Credits and Financial Consequences
Most enterprise SLAs include downtime credits: if the vendor breaches the SLA, affected customers receive account credits or cash-back as compensation.
A typical structure:
| Uptime Achieved | Credit |
|---|---|
| 99.0% to 99.9% (breach of 99.9% SLA) | 10% of monthly fee |
| 95.0% to 99.0% | 25% of monthly fee |
| Below 95.0% | 50% of monthly fee |
For a $50,000 ARR customer billed monthly (~$4,167/month), a 10% credit is $417. A serious outage affecting 50 enterprise accounts costs over $20,000 in credits alone before you count engineering time, churn risk, or sales impact.
How to Measure Your Actual Uptime
Uptime monitoring tools calculate uptime as:
Uptime % = ((Total checks - Failed checks) / Total checks) × 100
With 1-minute check intervals, you get 43,200 checks per month. A 30-minute outage represents 30 failed checks out of 43,200, or 99.93% uptime for that month.
Accuracy depends on detection speed. With 5-minute check intervals, a 6-minute outage might register as only 1 failed check (99.998% apparent uptime) even though users experienced a real disruption. The monitoring interval determines how accurately you can report SLA compliance.
What counts as downtime
Different organizations count downtime differently. Common definitions:
- Hard downtime: The service is completely unreachable (connection refused, DNS failure)
- Degraded uptime: The service responds but is slow or returning errors (often excluded from SLA calculations in vendor contracts)
- Partial outage: Only some users or regions are affected (typically counted proportionally)
Read your SLA contract's definition before assuming your monitoring numbers align with what you owe customers.
Uptime Targets by Service Type
| Service Type | Typical SLA Target | Reasoning |
|---|---|---|
| Developer API | 99.9%–99.99% | Developers build on it; outages cascade |
| Payment processing | 99.99%+ | Direct revenue impact per minute |
| SaaS dashboard | 99.9% | Users tolerate occasional unavailability |
| Authentication service | 99.99% | Every user flow depends on it |
| Background jobs / cron | 99.9% (via heartbeat monitoring) | Silent failures, no direct user impact |
| Marketing/content site | 99%–99.9% | No real-time transaction dependency |
Frequently Asked Questions
What is the difference between uptime and availability?
Uptime and availability are often used interchangeably but have a technical distinction. Uptime refers to the total time a system has been running without interruption. Availability is the ratio of time the service is accessible to users, accounting for planned maintenance, failover time, and partial outages. In SLA contexts, "uptime" typically means availability.
Does planned maintenance count against uptime SLA?
In most SLAs, scheduled maintenance windows are excluded from uptime calculations if the customer receives advance notice (typically 48-72 hours). Unplanned downtime always counts. Read your SLA to confirm your vendor's definition.
How do cloud providers calculate uptime?
AWS, Google Cloud, and Azure each define service uptime per product. AWS EC2 promises 99.99% for multi-region deployments but only 99.5% for single-region instances. Most providers calculate monthly uptime percentages and issue credits when the percentage falls below their commitment.
What monitoring interval do I need for accurate SLA reporting?
For 99.9% SLA reporting, 1-minute check intervals provide sufficient resolution. For 99.99% SLAs, 30-second intervals are the practical minimum since a single 1-minute outage can consume a significant portion of your monthly allowance. With 5-minute intervals, short outages may not register at all, giving you artificially inflated uptime numbers.
Can I report 100% uptime?
In practice, no system achieves 100% uptime over any meaningful period. Even brief DNS propagation delays, TLS renegotiations, and load balancer health checks can cause momentary check failures. Most monitoring tools treat uptime over 99.999% in a given month as functionally equivalent to 100%.
Vantaj monitors your uptime from 10 global probe regions with 30-second check intervals, giving you the resolution to report SLA compliance accurately and catch incidents before your customers do.
→ Start monitoring for free — no credit card required.