Convert SLA percentages to downtime per year/month/week and calculate composite SLA for multi-service architectures.
Last verified: May 2026
Output will appear here...The calculator multiplies the SLA fraction by the chosen time window (year, month, week, day) to compute the allowed-uptime number, then subtracts from the total to give the downtime budget. Composite calculation in series multiplies SLA fractions; parallel composite calculation uses the complement of the product of failure rates. Results are surfaced in both 'minutes per year' and 'percentage' so different audiences can use the number that resonates.
An SLA stated as a percentage hides how much downtime it actually permits. 99.9% sounds high until you realize it allows 8.76 hours of downtime per year. 99.99% allows 52.6 minutes — that is a lunch break of outage. The SLA Uptime Calculator converts SLA percentages into concrete downtime budgets per year, per month, per week, and per day, and computes the composite SLA when multiple services are chained in serial — which is how most real architectures break their promises.
Sales wants to put a 99.99% SLA in a new enterprise contract. You enter the architecture into the calculator: load balancer (99.99%), API gateway (99.95%), application tier (99.95%), database (99.95%). The composite serial SLA is 99.84% — meaning the team would be over-promising by 1.5 hours per year of downtime. You push back; sales agrees to 99.9% with a credit schedule beyond that. Six months later when an unrelated regional outage costs 40 minutes, the contract terms hold instead of triggering a refund clause.
If your incident response process takes 30 minutes from page to mitigation, you cannot truthfully offer better than 99.99% — a single incident per year consumes most of the budget. Either invest in faster MTTR or commit to a lower SLA.
Maintenance windows count as downtime in most customer-facing SLAs. The fastest way to inflate your SLA on paper is to define 'scheduled maintenance' as exempt — and to actually communicate those windows. The next-fastest way is to deploy non-disruptively.
For services chained in series (request must succeed at all of them), the composite is the product of the individual SLAs. Three services each at 99.95% give a composite of 99.85% — about 13 hours of allowable downtime per year. For services in parallel (any one will do, with proper failover), the composite is 1 minus the product of failure rates and is dramatically higher.
An SLA is a contractual commitment; measured uptime is what you observed. Healthy organizations measure higher than they commit, because committing exactly to measured uptime leaves no error budget for the next bad quarter. The gap between measured and committed is the budget you spend on risky deploys, capacity tests, and recovery drills.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.