Convert any SLA uptime percentage to exact allowed downtime per minute, hour, day, week, month, and year. Calculate your error budget, estimate financial impact of downtime, and compute compound SLA for multi-service architectures.
✓Verified: Google SRE error budget methodology & industry SLA standards — April 2026
⏱ SLA Uptime Tools
Enter SLA% e.g. 99.9, 99.95, 99.99, 99.999Enter a percentage between 50 and 100.
For financial impact estimate (leave blank to skip)
Monthly Downtime
—
⚠️ Disclaimer: Downtime calculations are based on calendar time. Actual SLA terms vary by provider and may exclude planned maintenance, force majeure, and customer-caused incidents. Financial impact estimates are illustrative only.
Your SLA commitment e.g. 99.9Enter a percentage between 50 and 100.
Total minutes of downtime so far this calendar monthEnter minutes consumed (0 or more).
Budget Remaining
—
Enter the SLA% for each service in your stack. Combined availability = product of all individual SLAs.
Compound SLA
—
Sources & Methodology
✓Calculations based on calendar time periods: 1 year = 8,760 hours = 525,600 minutes. Downtime = (1 - SLA/100) x period duration. Error budget methodology from Google Site Reliability Engineering. Compound SLA = product of all individual availability fractions.
Google SRE book defining the error budget concept: the total allowed downtime for a given SLA period. Popularized treating reliability as a feature with a quantifiable budget that teams can spend on deployment risk.
AWS official SLA documents for EC2, S3, RDS, and other services defining uptime commitments, measurement methodology, exclusions, and service credit calculation procedures.
Microsoft Azure SLA summary page covering uptime guarantees for Virtual Machines, SQL Database, App Service, and other Azure services. Used as the basis for cloud provider SLA comparison data in this calculator.
SLA Uptime Guide: What Every Network Engineer Needs to Know
Service Level Agreements define the availability commitment your infrastructure, cloud provider, or managed service vendor makes to you or your customers. Understanding what those percentages actually mean in minutes of downtime, how to track your error budget, and how individual SLAs combine in multi-service systems is essential for every network engineer, DevOps practitioner, and IT manager. This guide covers every aspect of SLA calculation with worked examples and the complete nines reference table.
Allowed Downtime = (1 - SLA%) x Period DurationMonthly Downtime (min) = (1 - SLA/100) x 43,800Annual Downtime (min) = (1 - SLA/100) x 525,600Error Budget Remaining = Total Budget - Consumed DowntimeCompound SLA = SLA1 x SLA2 x SLA3 x ... (as decimals)
Example: 99.9% monthly SLA
(1 - 0.999) x 43,800 = 43.8 minutes allowed per month
(1 - 0.999) x 525,600 = 525.6 minutes = 8.76 hours allowed per year Compound example: 99.99% x 99.95% x 99.9% = 99.84% combined
The Complete Nines Reference Table
Each additional nine reduces allowed annual downtime by approximately 90 percent and requires significantly more complex infrastructure to achieve.
SLA
Nines
Monthly Downtime
Annual Downtime
Typical Use Case
99%
Two 9s
7.2 hours
87.6 hours
Basic hosting, dev environments
99.5%
Two 9s+
3.6 hours
43.8 hours
Small business web hosting
99.9%
Three 9s
43.8 min
8.76 hours
Standard cloud SLA, most SaaS
99.95%
Three 9s+
21.9 min
4.38 hours
Business-critical cloud services
99.99%
Four 9s
4.38 min
52.6 min
AWS EC2, Azure VM, GCP Compute
99.999%
Five 9s
26.3 sec
5.26 min
Telecom, financial trading
99.9999%
Six 9s
2.6 sec
31.5 sec
Power grid, emergency systems
Major Cloud Provider SLA Comparison 2026
Understanding what each cloud provider actually commits to helps you design architectures that meet your availability requirements and negotiate SLAs with your own customers.
Provider
Service
SLA
Monthly Downtime
AWS
EC2 (single region)
99.99%
4.38 min
AWS
S3
99.99%
4.38 min
AWS
RDS Multi-AZ
99.95%
21.9 min
Azure
Virtual Machines (availability set)
99.99%
4.38 min
Azure
SQL Database Business Critical
99.995%
2.19 min
GCP
Compute Engine
99.99%
4.38 min
GCP
Cloud SQL
99.95%
21.9 min
Error Budget: The Google SRE Approach to Reliability
The error budget concept, popularized by Google Site Reliability Engineering, treats reliability as a feature with a measurable budget. For a 99.9% monthly SLA, your error budget is 43.8 minutes. When you have budget remaining, your team can deploy new features, updates, and infrastructure changes with confidence because you can absorb some additional risk. When the budget is nearly exhausted, all engineering effort must shift to stability — deferring non-critical changes and prioritizing incident prevention over feature delivery. This creates a healthy feedback loop: the reliability of the system directly controls the pace of change. Teams that cause outages lose their deployment window. Teams that maintain high reliability earn the right to move faster.
💡 Error budget rule of thumb: If you have consumed more than 80% of your monthly error budget before the 20th of the month, freeze all non-critical deployments. Real-time monitoring with fast polling intervals (30 seconds or less) is essential to detect incidents before they consume large amounts of budget.
When your service depends on multiple components that must all be available simultaneously, the combined availability is the product of all individual availability fractions. Three services each at 99.9% give a compound SLA of 0.999 x 0.999 x 0.999 = 99.7% — that is 2.19 hours of allowed monthly downtime instead of 43.8 minutes. Each dependency reduces overall availability. This is a critical consideration in microservices architectures: 20 services each at 99.9% compound to just 98.02% overall, allowing 8.68 hours of monthly downtime. The solution is redundancy at each dependency level, circuit breakers that allow graceful degradation, and async patterns that decouple services where possible.
MTBF and MTTR: Availability from Operational Data
Availability can also be calculated from operational incident data using MTBF and MTTR. Availability = MTBF / (MTBF + MTTR). If a system fails on average every 720 hours (MTBF) and each incident takes 1 hour to resolve (MTTR), availability equals 720 / (720 + 1) = 99.86%. To improve availability, reducing MTTR through automation, runbooks, and on-call engineering is typically faster and cheaper than reducing the failure rate itself. Each minute saved on mean time to recovery directly improves availability.
Frequently Asked Questions
99.9% uptime (three nines) allows 43.8 minutes of downtime per month. Calculated as (1 minus 0.999) multiplied by 43,800 minutes per month. Per year this equals 8.76 hours of allowed downtime. This is the standard baseline SLA offered by most web hosting providers and cloud services.
99.99% uptime (four nines) allows 52.6 minutes of downtime per year, or 4.38 minutes per month. This requires highly redundant infrastructure with automatic failover, load balancing, and geographic redundancy. AWS, Azure, and GCP offer 99.99% SLA for their core compute services.
Downtime = (1 minus SLA%) multiplied by the total period duration. For 99.9% monthly: (1 minus 0.999) x 43,800 minutes = 43.8 minutes. For 99.95% annual: (1 minus 0.9995) x 525,600 minutes = 262.8 minutes. Use the calculator above for any SLA percentage and see results across all time periods instantly.
An error budget is the total allowed downtime for a given SLA period. Popularized by Google SRE, it treats reliability as a feature with a measurable budget. For 99.9% monthly SLA, error budget is 43.8 minutes. When budget is healthy, teams deploy changes. When it runs low, all effort shifts to stability. It creates a direct feedback loop between reliability and deployment velocity.
Compound SLA is the combined availability of multiple services that must all be available simultaneously. Formula: combined SLA = SLA1 x SLA2 x SLA3 (as decimals). Three services at 99.9% each give 0.999 x 0.999 x 0.999 = 99.7% compound SLA. This is why microservices architectures with many dependencies can struggle to achieve high overall availability.
Five nines = 99.999% uptime = 5.26 minutes of allowed downtime per year = 26.3 seconds per month. This requires fully redundant active-active systems with sub-second failover, no planned maintenance windows, and mature incident response. Financial trading systems, emergency services, and some telecommunications infrastructure target five nines availability.
Gartner estimates average enterprise downtime cost at USD 5,600 per minute for large enterprises. For e-commerce, revenue loss equals hourly revenue divided by 60 multiplied by downtime minutes. Add incident response staff cost, customer compensation, and reputational impact. Enter your hourly revenue in the SLA calculator above to get a financial impact estimate for your specific downtime budget.
MTBF (Mean Time Between Failures) is the average time a system operates between failures. MTTR (Mean Time To Recovery) is the average time to restore service after a failure. Availability = MTBF / (MTBF plus MTTR). Reducing MTTR through automation and runbooks typically improves availability faster and more cost-effectively than trying to reduce failure frequency.
AWS EC2 offers 99.99% SLA per region. AWS S3 offers 99.99%. Azure Virtual Machines offer 99.99% for availability sets. Azure SQL Database Business Critical offers 99.995%. Google Cloud Compute Engine offers 99.99%. All major providers exclude scheduled maintenance, force majeure, and customer-caused outages from SLA calculation.
Track all incidents in an incident log with start time, end time, and duration. At month end: uptime% = (43,800 minus total downtime minutes) / 43,800 x 100. Use monitoring tools with sub-minute polling to detect outages quickly. Most SLAs require documentation of incidents to receive service credits, so accurate tracking is also necessary for compensation claims.
SLA definitions vary but typically count downtime as periods when the service is completely unavailable or when error rates exceed a defined threshold. Most SLAs explicitly exclude planned maintenance windows, force majeure events, customer-caused issues, and DNS or network problems outside the provider's control. Always read SLA exclusions carefully before signing a contract.
Uptime% = (Total period minutes minus total downtime minutes) / total period minutes x 100. For a month (43,800 minutes) with 3 incidents totaling 120 minutes: (43,800 minus 120) / 43,800 x 100 = 99.726% uptime. Track partial outages too: many SLAs count degraded performance above an error rate threshold as downtime even if the service is not completely unavailable.
With N dependencies each at the same SLA%, combined availability = SLA%^N. For overall 99.9% target with all services at 99.99% each: 0.9999^N = 0.999, solving: N = log(0.999) / log(0.9999) = approximately 10 services. With 10 services each at 99.99%, you achieve a combined 99.9% SLA. More dependencies require higher individual SLAs to maintain the same overall target.