DevOps Tools

SLA & Uptime Calculator

See how much downtime an SLA such as 99.9% or 99.99% allows per day, week, month, quarter and year, convert an outage into the uptime you actually achieved, calculate the composite availability of services in series or behind redundancy, and track how fast you are burning an SLO error budget.

Private by design: anything you enter is processed in your browser only. It is never uploaded to or logged on our servers. Your SLA targets, outage figures and service names stay on this device.

A quarter is a quarter of the year; the average month is 365.25 / 12 days.

Unavailability:
Number of nines:
Allowed downtime

Common SLA levels (with your month and year settings)

SLA Per day Per week Per month Per quarter Per year

About SLAs, uptime and error budgets

An availability target such as 99.9% ("three nines") is easier to reason about as time: it allows 0.1% of the period to be down, which is about 1 minute 26 seconds a day, 43 minutes 50 seconds in an average month or 8 hours 46 minutes a year. Each extra nine divides the allowance by ten, so 99.99% leaves roughly 4 minutes a month and 99.999% about 26 seconds, which is less than a typical deploy, DNS change or failover takes. This calculator does the conversion for any target and shows the result for every common period.

Monthly figures depend on how long a "month" is. By default the calculator uses an average month of 365.25 ÷ 12 = 30.4375 days and a 365.25-day year (the Julian year; the Gregorian average of 365.2425 days differs by only about 0.002%); switch to 28, 30 or 31 days to match the billing month in a specific contract, because many cloud SLAs measure availability per calendar month. A quarter is always a quarter of the selected year length.

Real systems are chains of dependencies. When a request needs every component (load balancer, app, database) the availabilities multiply, so three 99.9% services in series give only about 99.7%. Redundancy works the other way: independent replicas fail together only when all of them are down, so two 99% instances in parallel reach 99.99%. The composite tab combines both, but remember the formulas assume independent failures. Shared power, a common region, the same bad deploy or a single DNS provider breaks that assumption.

An error budget is the unreliability your SLO permits: a 99.9% SLO over 30 days allows 43.2 minutes of downtime. Teams spend it on releases and experiments and slow down when it runs out. The burn rate tells you how fast you are spending it: 1× means you will use exactly the whole budget by the end of the window, while 14.4× sustained for one hour consumes 2% of a 30-day budget, the classic fast-burn paging threshold. For capacity planning, pair this with the throughput estimator, and measure real outages from your access logs with the log analyzer.

Reference Guide

The "nines" (average month = 30.4375 days, year = 365.25 days):

AvailabilityNinesDowntime / dayDowntime / monthDowntime / year

Formulas (availability a as a fraction, e.g. 99.9% = 0.999):

QuantityFormulaExample
Allowed downtime(1 − a) × period0.001 × 30 days = 43.2 min
Achieved uptime1 − downtime ÷ period1 − 90 min ÷ 43,830 min = 99.795%
Series (all required)a₁ × a₂ × … × aₙ0.999 × 0.9995 × 0.9999 = 99.84%
Parallel (any one suffices)1 − (1 − a₁)(1 − a₂)…(1 − aₙ)Two at 99%: 1 − 0.01² = 99.99%
Nines−log₁₀(1 − a)99.95% → 3.3 nines
Error budget(1 − SLO) × window99.9%, 28 days → 40.3 min
Burn rate(budget used ÷ budget) ÷ (time elapsed ÷ window)50% used after 25% of the window = 2×

SLA vs SLO vs SLI:

TermMeaningExample
SLI (indicator)A measured ratio of good events to valid eventsShare of HTTP requests answered with a non-5xx status in under 300 ms
SLO (objective)The internal target for an SLI over a window99.9% of requests are good over a rolling 28 days
SLA (agreement)A contract with customers, with consequences (usually service credits) when missed99.9% monthly uptime, 10% credit below it
Error budget1 − SLO: the unreliability you are allowed to spend0.1% of requests, or 43.2 min per 30 days

SLOs are normally set tighter than the SLA so you are warned before breaching the contract.

Multi-window burn-rate alerts for a 30-day SLO (from the Google SRE Workbook):

Burn rateLong windowBudget consumedAction
14.4×1 hour2%Page
6×6 hours5%Page
1×3 days10%Ticket

Example input

SLA 99.9%  →  1m 26.4s / day, 43m 49.8s / month (30.4375 d), 8h 45m 57.6s / year (365.25 d)
Composite: Load balancer 99.99% · App 99.9% × 2 copies · Database 99.95% (series)
Error budget: SLO 99.9% over 30 days, 12 days elapsed, 20 min down

This sample loads automatically when you open the tool. Use Load Sample to bring it back.

Frequently Asked Questions

About 43.8 minutes per month and about 8.77 hours per year. Each extra nine cuts the allowed downtime by a factor of ten.

Services that all must work (in series) multiply their availabilities, so two 99.9% services give about 99.8%. Redundant services in parallel combine as 1 minus the product of their unavailabilities.

The error budget is the downtime your SLO allows in a period, 100% minus the SLO. Teams spend it on releases and incidents and slow down changes when it runs out.