A 99.9% uptime target allows about 43 minutes of downtime in a 30-day month; 99.99% allows about 4 minutes. The extra nine cuts the error allowance by 90%, so it changes the architecture, incident response, and measurement discipline required.
This guide compares the two targets, gives the allowed downtime for every common tier from 99% to 99.999% with a formula for any custom target, and explains the contract details that decide whether an event counts. To measure your own service, see how to calculate website uptime.
What Is an Uptime SLA?
A Service Level Agreement (SLA) is a contract that defines the expected level of service and a remedy when that commitment is missed. Google SRE distinguishes it from an internal SLO: an SLA is an explicit or implicit agreement with consequences, while an SLO is the reliability target used to operate the service.
- Availability target — e.g., 99.9%
- How downtime is measured — usually from the customer's perspective
- Exclusions — planned maintenance, force majeure, customer-side issues
- Remedies — credits or penalties if the target is missed
The availability percentage is uptime over a period, usually calculated monthly or annually:
Availability % = (Total time − Downtime) / Total time × 100
The Downtime Math: What Each Tier Allows
A year has 525,600 minutes. Here's how much downtime each uptime tier permits:
| Uptime | Per day | Per week | Per 30-day month | Per quarter (90d) | Per year (365d) |
|---|---|---|---|---|---|
| 99% (two nines) | 14m 24s | 1h 40m 48s | 7h 12m | 21h 36m | 3d 15h 36m |
| 99.5% | 7m 12s | 50m 24s | 3h 36m | 10h 48m | 1d 19h 48m |
| 99.8% | 2m 52.8s | 20m 9.6s | 1h 26m 24s | 4h 19m 12s | 17h 31m 12s |
| 99.9% (three nines) | 1m 26.4s | 10m 4.8s | 43m 12s | 2h 9m 36s | 8h 45m 36s |
| 99.95% | 43.2s | 5m 2.4s | 21m 36s | 1h 4m 48s | 4h 22m 48s |
| 99.99% (four nines) | 8.64s | 1m 0.5s | 4m 19.2s | 12m 57.6s | 52m 33.6s |
| 99.995% | 4.32s | 30.24s | 2m 9.6s | 6m 28.8s | 26m 16.8s |
| 99.999% (five nines) | 0.86s | 6.05s | 25.92s | 1m 17.76s | 5m 15.36s |
Monthly figures use a 30-day month. Over an average calendar month (30.44 days), 99.9% allows about 43.8 minutes and 99.99% about 4.4 minutes, which is why both numbers appear in SLA documents.
These are mathematical allowances, not universal recommendations. The right target depends on user impact, dependency reliability, recovery capability, and what the agreement excludes.
How to calculate allowed downtime for any uptime %
Allowed downtime is the complement of uptime multiplied by the length of the window:
allowed_downtime_seconds = (1 - uptime_fraction) × window_seconds
window_seconds:
per day = 86,400
per week = 604,800
per 30 days = 2,592,000
per 90 days = 7,776,000
per 365 days = 31,536,000
For example, 99.97% per 30 days is (1 - 0.9997) × 2,592,000 = 777.6 seconds, or 12m 57.6s. 99.85% per year is (1 - 0.9985) × 31,536,000 = 47,304 seconds, or 13h 8m 24s.
Pick one window, write it into the SLA or SLO, and measure against that window. Most public SLAs are quoted per calendar month, while engineering teams often track a rolling 30-day or 90-day window.
99.9% vs 99.99%: The Practical Difference
Going from 99.9% to 99.99% doesn't sound like much. It's one more nine. But the impact is large:
| Metric | 99.9% | 99.99% |
|---|---|---|
| Downtime per year | 8.76 hours | 52.56 minutes |
| Downtime per month | ~44 minutes | ~4.4 minutes |
| Single longest "acceptable" outage | ~8–9 hours/year total | ~53 minutes/year total |
In practice:
- 99.9% — You can have a few multi-hour incidents per year and still meet the SLA.
- 99.99% — About 53 minutes of counted downtime consumes an annual budget, or about 4 minutes consumes a 30-day budget. You need fast detection, recovery, and protection against single points of failure.
So 99.99% doesn't just mean "a bit more uptime." It means you must detect and fix issues in minutes, not hours. That usually requires better monitoring, on-call processes, and redundancy.
How SLAs Are Measured (And Gamed)
Monthly vs annual
Many SLAs are calculated per month. That means:
- One bad month can trigger a credit even if the rest of the year was perfect.
- One perfect month doesn't protect you if the next month has a long outage.
Check whether your SLA is monthly or rolling annual.
Excluded downtime
Typical exclusions:
- Planned maintenance (if announced in advance)
- Force majeure (natural disasters, war, etc.)
- Customer-caused (wrong config, DDoS you didn't mitigate)
- Third-party (e.g. "we're not responsible if AWS is down")
Read the exclusions. They often swallow a big share of real-world downtime.
Measurement method
- Probe-based — Provider pings your endpoint from their locations. Can miss regional or routing issues.
- Synthetic monitoring — Scripts simulate user flows. Closer to real experience.
- Real user monitoring (RUM) — Actual user sessions. Most accurate but harder to contract on.
Your own monitoring (e.g. from multiple regions) may show more downtime than the provider's SLA measurement. That's why you need independent monitoring to verify SLAs and improve reliability.
Choosing the Right Uptime Target
When 99.9% is enough
- Internal tools, staging, non-critical APIs
- Blogs, marketing sites, low-transaction sites
- Early-stage products where speed of iteration matters more than perfect uptime
When to aim for 99.99%
- Payment, billing, or checkout flows
- Auth and login
- Core product used by paying customers
- APIs that other businesses depend on
When 99.999% is considered
- Banking, healthcare, safety-critical systems
- Regulated industries with strict availability requirements
- Extremely high revenue per minute of downtime
Do not copy a tier from another company. Start with the business impact and current baseline, then choose a target you can measure and engineer for. Keep the customer-facing SLA looser than the internal SLO and error-budget policy so teams have room to act before a contractual breach.
Monitoring Your Own SLA
If you promise 99.9% or 99.99%, you need to:
- Measure continuously — With checks at least every 1–5 minutes so you don't miss short outages.
- Measure from the user's perspective — HTTP(s), key pages, critical APIs.
- Track cumulative downtime — Know how many minutes you've "spent" each month/year.
- Alert before you breach — If you're approaching your allowed downtime, escalate.
Tools like Webalert give you uptime percentages, incident history, and status pages so you can report honestly to customers and improve over time.
SLA Credits: What They're Really Worth
Many providers offer service credits when they miss the SLA (e.g. 10% off next invoice). That can sound good until you do the math:
- Lost revenue or trust from an 8-hour outage often far exceeds 10% of your hosting bill.
- Credits don't fix the incident; they only soften the bill.
Use credits as a minimum. The real goal is fewer and shorter outages through better architecture and monitoring.
Summary: Key Takeaways
- 99.9% ≈ 8.76 hours downtime/year. 99.99% ≈ 53 minutes/year.
- The jump from 99.9% to 99.99% demands much faster detection and recovery.
- Read how the SLA is measured and what's excluded.
- Match the target to the business impact: 99.9% for non-critical, 99.99% for critical paths.
- Measure your own uptime independently and aim to beat your stated SLA.
Frequently Asked Questions
What does 99.9% uptime mean in minutes?
A 99.9% uptime SLA ("three nines") allows about 8 hours and 46 minutes of downtime per year, or roughly 43.8 minutes per month. That's enough headroom for a couple of short incidents, but a single multi-hour outage can blow the entire month's budget.
How much downtime is 99.99% uptime?
99.99% uptime allows 4 minutes 19 seconds of downtime per 30-day month, about 52 minutes 34 seconds per year, or 8.6 seconds per day. One incident longer than four minutes uses up the whole month's allowance.
What is the difference between 99.9% and 99.99% uptime?
99.99% uptime ("four nines") allows only 52.56 minutes of downtime per year — about one tenth of 99.9%. In practical terms, hitting 99.99% requires that you detect and resolve incidents in under an hour combined, which usually means automated monitoring, on-call rotations, and redundancy across regions or providers.
How do I measure my own uptime SLA?
Run independent uptime checks at least every 1–5 minutes from outside your infrastructure, track cumulative downtime per month and per year, and compare it to your stated SLA. Don't rely solely on your hosting provider's status page — it often excludes regional or partial outages that affect your customers. A monitoring tool like Webalert calculates uptime percentage and downtime minutes automatically. Need to verify if your site is currently down? Use our website down checker to test from outside your network.
Are SLA credits worth it?
Usually not on their own. A typical SLA credit returns 5–25% of the monthly fee when uptime falls below the promised target — that almost never covers the lost revenue or customer trust from a real outage. Treat credits as the minimum baseline and focus on architecture and monitoring that prevent the downtime in the first place.
What uptime target should a SaaS application aim for?
For most SaaS products, 99.9% is the practical baseline and 99.99% is the goal for revenue-critical paths like checkout, login, and core APIs. Going beyond 99.99% delivers diminishing returns for most teams and dramatically raises operating costs — reserve 99.999% for life-critical or regulated systems.
Monitor your uptime and prove your SLA
Measure your actual uptime independently with automated checks every minute from multiple global locations. Start free uptime monitoring → to track your SLA compliance and get instant downtime alerts.
Try the free plan → — 3 monitors with 10-minute checks, no credit card. See all features and pricing for faster intervals and more monitors.