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 |
|---|
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.
FAQ
What does 99.9% uptime mean in practice?
99.9% uptime means your service can be down for up to 43 minutes and 50 seconds per month, or about 8 hours and 46 minutes per year. It's the most common SLA level for SaaS products.
What is the difference between 99.9% and 99.99% uptime?
99.9% allows ~8h 46m of downtime per year. 99.99% allows only ~52 minutes per year, roughly 10 times less. The infrastructure cost and complexity to go from three nines to four nines is significant.
How do I calculate my SLA uptime percentage?
Use the formula: (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?
An error budget is the maximum amount of downtime your SLO allows in a given period. If your SLO is 99.9% monthly, your error budget is 43.2 minutes. Teams use it to balance reliability work against feature development.
What is the difference between SLA, SLO, and SLI?
An SLI is a measurement (e.g. request success rate). An SLO is your internal target for that measurement. An SLA is the contractual commitment you make to customers. SLOs are always set tighter than SLAs to create a safety buffer.
How often should I check my uptime to meet a 99.99% SLA?
At 99.99%, you only have ~4 minutes of downtime per month. You need monitoring checks every 30–60 seconds at minimum. Otherwise, a short outage could go undetected long enough to breach your SLA before you even know about it.
Can I monitor my SLA compliance automatically?
Yes. Tools like fivenines.io track your uptime continuously, calculate your error budget consumption in real time, and alert you before you breach your SLA, so you can act before customers notice.
Useful resources
- Google SRE Book: Service Level Objectives - the definitive reference on SLIs, SLOs, and SLAs
- Google SRE Workbook: Alerting on SLOs - practical guidance on error budget alerting
- MTTR Calculator - calculate your mean time to recovery
- Server Alerts - get notified before your error budget runs out
- Best Infrastructure Monitoring Tools - compare 15 tools including FiveNines, Datadog, and Grafana
See how FiveNines compares: vs UptimeRobot · vs Better Stack
Track your uptime and error budget automatically
Start monitoring with fivenines.io