Per day
—
What "uptime" and "SLA" actually mean
Uptime is the fraction of a period a system is available, expressed as a percentage such as 99.9%. A Service Level Agreement (SLA) is a contractual promise pinned to that percentage — cloud providers, hosting companies, and internal platform teams publish an uptime target and, in many contracts, pay a service credit if they miss it. The relationship between uptime and downtime is simple arithmetic: for any period, downtime = period_length × (1 − uptime/100). A "nine" refers to how many 9s appear in the percentage: 99% is "two nines," 99.9% is "three nines," 99.99% is "four nines," and so on. Each additional nine cuts the allowed downtime by roughly a factor of ten, which is why the jump from 99.9% to 99.99% is a much bigger engineering lift than the jump from 99% to 99.9%.
Why the numbers differ from other calculators
The most common source of disagreement between SLA calculators is the definition of a month and a year. This tool uses a 365-day year and derives the "average month" as 365 ÷ 12 ≈ 30.44 days, which is the convention used by most independent SLA reference tools and reproduces the widely cited figures for 99.9% (8h 45m/year, 43m 48s/month). If you need downtime for an exact calendar month — say, credits under a specific billing cycle — use the reverse calculator and enter the exact number of days for that month via the day/week period options, or scale the yearly figure by (days_in_month ÷ 365).
Worked examples
Example 1 — Forward: what does 99.95% allow?
Uptime target: 99.95%. Downtime fraction = 1 − 0.9995 = 0.0005.
Per day: 86,400 s × 0.0005 = 43.2 s → 43.2 seconds Per week: 604,800 s × 0.0005 = 302.4 s → 5m 2.4s Per month: 2,628,000 s × 0.0005 = 1,314 s → 21m 54s Per year: 31,536,000 s × 0.0005 = 15,768 s → 4h 22m 48s
So a 99.95% SLA gives you 21 minutes 54 seconds of downtime per month to work with — that's your error budget for the tool below.
Example 2 — Reverse: a 22-minute outage this month
Downtime: 22 minutes in a 30.44-day month. Month length = 2,628,000 seconds. 22 minutes = 1,320 seconds.
Downtime fraction = 1,320 / 2,628,000 = 0.00050228... Uptime = (1 − 0.00050228) × 100 = 99.949771...% Rounded: 99.9498% uptime for the month
A single 22-minute incident in an otherwise perfect month lands you at roughly 99.95% — right at the edge of a three-and-a-half-nines SLA, and already over budget against a 99.95% target since the 21m54s allowance is exceeded by 6 seconds.
Composite SLA: series vs. parallel
Real systems are rarely a single service — they're a chain of dependencies, sometimes with redundancy layered on top. Composite SLA math tells you the actual effective uptime of the whole system, which is very different from any single component's published number.
- Series (dependency chain): if your API depends on a database and a queue, and any one of them being down takes the whole request down, multiply the uptime fractions:
combined = u1 × u2 × u3. Three services each rated at 99.9% combine to only 99.7% — worse than any individual component, because all three must be up at once. - Parallel (redundant failover): if two regions run active-active and only one needs to be up, multiply the downtime fractions instead:
combined = 1 − (d1 × d2)wheredi = 1 − ui. Two independent 99.9% regions combine to 99.9999% — far better than either region alone, because both would have to fail at the same time.
Example 3 — Two-service composite
Service A = 99.95%, Service B = 99.9%.
Series: 0.9995 × 0.999 = 0.9985005 → 99.85005% combined (worse than either alone)
Parallel: dA=0.0005, dB=0.001
1 − (0.0005 × 0.001) = 1 − 0.0000005 = 0.9999995 → 99.99995% combined (better than either alone)
How to use the monthly error budget
An error budget treats your SLA target as a spendable allowance rather than a pass/fail gate. Pick a target (e.g. 99.95%), a period (usually month), and enter downtime already used from incidents this period. The tracker shows the total budget, what's left, and what percentage of the budget you've already spent — the same mental model SRE teams use to decide whether to freeze risky deploys or keep shipping.
Frequently asked questions
How much downtime does 99.9% uptime actually allow?
99.9% uptime (three nines) allows about 1 minute 26 seconds of downtime per day, 10 minutes 5 seconds per week, 43 minutes 48 seconds per month (using a 30.4-day average month), and 8 hours 45 minutes 36 seconds per year. The math: downtime = period length × (1 − uptime fraction), so for a year that's 365 days × 24 hours × 0.001.
Why does my downtime-to-uptime result differ slightly from other calculators?
The difference almost always comes from how a month or year is defined. This tool uses a 365-day year and derives the month as year ÷ 12 (about 30.44 days), matching how most SLA and status-page tools compute figures. A calculator using flat 30-day months or 365.25-day years will land a few seconds off.
How is composite SLA calculated for services in series?
When the whole request fails if any dependency is down (a serial chain, like an API calling a database calling a queue), combined uptime is the product of each service's uptime fraction: combined = u1 × u2 × u3. Chaining dependencies always lowers effective uptime below the weakest link.
How is composite SLA calculated for services in parallel?
When services are redundant and only one needs to be up (active-active replicas, multi-region failover), combined downtime is the product of each service's downtime fraction: combined = 1 − (d1 × d2 × d3) where each di = 1 − ui. Redundancy always raises effective uptime above the strongest individual component.
What is an SLA error budget and how do I read the remaining budget?
An error budget is the total downtime a target SLA allows for a period, treated as a spendable allowance. If your target is 99.95% for a 30-day month, the budget is about 21 minutes 54 seconds. If an incident already used 8 minutes, remaining budget is about 13 minutes 54 seconds, roughly 63% left before you breach the SLA.
Does this tool send my SLA numbers or incident data anywhere?
No. Every calculation runs in plain JavaScript in your browser on the numbers you type in. There is no server call, no analytics tied to your inputs, and no network request after the page loads, so it's safe to use with real internal SLA targets or incident numbers.
Should I use calendar days or a 30.44-day average month for SLA credits?
Most published cloud SLAs define the billing period as the actual calendar month, so a 28-day February has a smaller downtime allowance than a 31-day month at the same percentage. This tool defaults to an average 30.44-day month for quick comparisons, but you can switch the period selector to Day, Week, or Year for more exact figures.