SLA Uptime Calculator
How much downtime does your SLA actually allow?
Going from 99.9% to 99.99% cuts your allowed downtime by 10x, from ~44 minutes to ~4 minutes per month.
Quick reference
| SLA | Per day | Per week | Per month | Per quarter | Per year |
|---|---|---|---|---|---|
| 99% | 14m 24s | 1.7h | 7.2h | 21.8h | 3.7d |
| 99.9% | 1m 26s | 10m 5s | 43m 12s | 2.2h | 8.8h |
| 99.95% | 43s | 5m 2s | 21m 36s | 1.1h | 4.4h |
| 99.99% | 9s | 1m 0s | 4m 19s | 13m 6s | 52m 34s |
| 99.999% | 1s | 6s | 26s | 1m 19s | 5m 15s |
SLA, SLO, SLI: What's the difference?
SLI (Service Level Indicator)
The raw measurement. The ratio of good events to total events over a time window (e.g. "99.95% of requests returned HTTP 200 in the last 30 days").
SLO (Service Level Objective)
Your internal target for an SLI. "We aim for 99.9% availability" is an SLO. Miss it and your team gets paged. It's a threshold you set for yourself.
SLA (Service Level Agreement)
A contract with your customers. If you promise 99.9% uptime and miss it, you owe credits or refunds.
In practice: set your SLO tighter than your public SLA. If your SLA is 99.9%, your SLO should be 99.95% or higher, so you have a buffer before contractual penalties kick in.
How to calculate allowed downtime from an SLA percentage
The formula is simple:
Allowed downtime = Total minutes in period × (1 - SLA%)
Monthly example for 99.9% SLA:
43,200 min × (1 - 0.999) = 43.2 minutes
A month has 43,200 minutes (30 days × 24h × 60min). A year has 525,600 minutes.
Each additional "nine" cuts allowed downtime by a factor of 10. Going from 99.9% to 99.99% means going from ~43 minutes/month to ~4.3 minutes. That's the difference between "we can schedule a maintenance window" and "every second counts."
Common SLA tiers: which one do you need?
99% (two nines) - 7h 12m/month
Fine for internal tools, staging environments, and non-critical batch jobs. You get over 3.5 days of downtime per year. Most internal dashboards operate here without complaints.
99.9% (three nines) - 43m 50s/month
The most common SLA for SaaS products and business web apps. Achievable with basic redundancy, health checks, and a solid deployment process. Most startups and mid-size companies target this tier.
99.95% (three-and-a-half nines) - 21m 54s/month
A good middle ground for B2B SaaS with paying customers who expect more than "standard" reliability, without the infrastructure cost of four nines.
99.99% (four nines) - 4m 22s/month
Required for payment processing, authentication services, and APIs that other businesses depend on. Demands redundant infrastructure across availability zones, automated failover, and zero-downtime deployments.
99.999% (five nines) - 26s/month
Telecoms, emergency services, and core financial infrastructure. At this level, even rolling upgrades and certificate rotations must be seamless. Very few organizations genuinely operate at five nines end-to-end.
Error budgets explained
An error budget flips the SLA question: instead of "how much uptime do we need?", it asks "how much downtime can we afford to spend?"
If your SLO is 99.9% monthly, you have 43.2 minutes of budget. Every incident eats into it:
- A 15-minute outage → 28.2 minutes left for the rest of the month
- A risky deployment that goes wrong → costs 5 minutes of budget
When the budget is healthy: ship features, experiment, take calculated risks. When the budget is nearly spent: shift to reliability work. Fix flaky tests, improve rollback speed, add better monitoring.
No arguments about priorities needed. The number decides.
The key insight: some downtime is acceptable. Chasing 100% uptime is infinitely expensive and slows down everything else. Error budgets let you move fast while staying accountable to your customers.
Why SLA monitoring matters
Knowing your SLA target is one thing. Knowing whether you're actually meeting it is another.
Without continuous monitoring, you're guessing at your actual availability. A 3-minute blip at 2 AM that nobody noticed still counts against your SLA, and those small incidents add up faster than most teams expect.
The worst scenario: finding out you've breached your SLA from a customer, not from your own monitoring. By then, the damage is done. Credits are owed, trust is lost, and you're debugging an incident with cold logs and fuzzy memories.
Effective SLA monitoring means:
- Checking your services every 30–60 seconds
- Tracking availability over rolling windows that match your SLA period
- Alerting your team before the error budget runs out, not after
- Setting warnings at 50% budget consumed, critical alerts at 80%
That gives you time to react before a breach, not after.
Fivenines can track uptime windows and alert your team before the error budget runs out, not after.
FAQ
What does 99.9% uptime mean in practice? +
What is the difference between 99.9% and 99.99% uptime? +
How do I calculate my SLA uptime percentage? +
(Total time - Downtime) / Total time × 100. For example, if your service was down for 1 hour in a 30-day month (43,200 minutes), your uptime is (43,200 - 60) / 43,200 × 100 = 99.86%.
What is an error budget? +
What is the difference between SLA, SLO, and SLI? +
How often should I check my uptime to meet a 99.99% SLA? +
Can I monitor my SLA compliance automatically? +
Explore next
Useful resources
Google SRE Book: Service Level Objectives
The definitive reference on SLIs, SLOs, and SLAs.
Explore ->Google SRE Workbook: Alerting on SLOs
Practical guidance on error budget alerting.
Explore ->MTTR Calculator
Calculate your mean time to recovery.
Explore ->Server Alerts
Get notified before your error budget runs out.
Explore ->See how Fivenines compares to other tools
Read our guide to the best infrastructure monitoring tools in 2026.
Track your uptime and error budget automatically
Start monitoring with fivenines.io