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.
The Problem an SLA Calculator Solves
A raw uptime percentage like "99.95%" is nearly meaningless until it's translated into actual time — engineers and stakeholders reason in minutes and hours, not in fractions of a percent. An SLA (Service Level Agreement) calculator converts an uptime percentage into concrete allowed downtime figures per day, week, month, and year, so "five nines" becomes the much more legible fact that 99.999% 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.
How It Works Under the Hood
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.
Real-World Use Cases
- 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.
Best Practices & Tips
- Set internal SLOs at least one nine tighter than your external SLA: If you've contractually committed to 99.9%, target 99.95% internally so an ordinary bad day doesn't immediately become a contractual breach — the gap is your error budget.
- Calculate composite SLA before you finalize an architecture, not after: Five services at 99.95% each in a synchronous critical path compound to roughly 99.75% — nearly an extra hour of yearly downtime versus a single service, often a surprise to teams who only check each dependency's SLA in isolation.
- Use redundancy math, not addition, for parallel paths: Two independent paths each with 99% availability in an active-active failover configuration combine to roughly 99.99% availability (
1 - (1-0.99)×(1-0.99)), not 198% — model failover paths multiplicatively against their failure probability, not their uptime. - Track planned maintenance separately from your SLA budget: Most vendor SLAs exclude scheduled maintenance windows from downtime calculations — confirm whether your own internal SLO does the same, since silently excluding maintenance windows can mask a genuine reliability problem.
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.