SLA & Uptime Calculator
Convert uptime percentages to allowed downtime per year, month, week and day. Calculate composite SLAs for multi-service systems where all services must be available.
When services run in series, the combined SLA is the product of all individual SLAs. Add each service below.
What is an SLA Calculator?
An SLA (Service Level Agreement) calculator converts an uptime percentage into concrete allowed downtime figures — per day, week, month, and year. For DevOps and SRE engineers, understanding what "five nines" actually means in practice is far more useful than the raw percentage. 99.999% sounds impressive until you realise it permits only about 5 minutes of downtime per year.
SLAs are binding contractual commitments between service providers and their customers, often carrying financial penalties when breached. Engineering teams use uptime calculations to set realistic SLO (Service Level Objective) targets and to understand the headroom they have before a contractual violation occurs. This tool also calculates composite SLAs for systems built from multiple dependencies — a critical step when architecting microservices or multi-cloud infrastructure.
When to Use This Tool
- Evaluating cloud provider SLAs: Translate vendor uptime percentages (AWS, Azure, GCP) into real downtime budgets so you can assess whether they meet your reliability requirements.
- Setting SLO targets: Calculate the allowed downtime budget before committing to an SLO, ensuring your internal objective is achievable given infrastructure constraints.
- Designing resilient architectures: Use composite SLA calculation to understand how chaining multiple services degrades overall reliability, and decide where to add redundancy.
- Negotiating vendor contracts: Come to SLA negotiations with concrete downtime figures to quantify the real-world impact of different uptime tiers on your business.
How It Works
The calculator converts a percentage to downtime using the formula: downtime = period × (1 - SLA%/100). For a 99.9% SLA over a 30-day month, that is 30 × 24 × 60 × (1 - 0.999) = 43.2 minutes. Composite SLA for services in series is computed by multiplying each individual SLA together: composite = SLA_A × SLA_B × SLA_C. This reflects the statistical reality that every additional dependency in the critical path reduces the system's overall availability, since all components must be operational simultaneously.
Frequently Asked Questions
What does 99.9% SLA mean in practice?
A 99.9% SLA (three nines) allows approximately 8 hours and 46 minutes of downtime per year, or about 43 minutes per month. While that sounds modest, for a customer-facing e-commerce platform, 43 minutes of monthly downtime during peak hours could translate into significant lost revenue and customer churn. Engineering teams typically target an internal SLO stricter than the SLA — for instance, an internal 99.95% target to ensure they have a safety buffer before a contractual breach.
How is composite SLA calculated?
Composite SLA is calculated by multiplying the individual SLAs of all services in series. For example, if Service A has 99.9% and Service B has 99.95%, the composite SLA is 99.9% × 99.95% = 99.85%. This multiplicative degradation means that adding more dependencies always reduces overall availability — even if every individual service is highly reliable. For this reason, architects aim to minimise the number of synchronous dependencies in the critical path, and use async patterns or caching to decouple services where possible.
What is the difference between an SLA, SLO, and SLI?
An SLI (Service Level Indicator) is the actual metric being measured, such as request latency, error rate, or availability percentage — the raw signal from your monitoring system. An SLO (Service Level Objective) is the internal target you set for that SLI, for example "99.9% of requests succeed" or "p99 latency stays below 500ms". An SLA (Service Level Agreement) is the formal contractual commitment made to customers, typically with financial penalties such as service credits for breaches. Best practice is to set SLOs tighter than SLAs so that engineering teams receive an early warning before a customer-facing commitment is violated.