Uptime & SLA Calculator: Downtime for 99.9%, 99.99% and More (2026)

Quick answer: 99.9% uptime allows about 43 minutes 48 seconds of downtime per month (43 minutes 12 seconds over an exact 30 days), 8 hours 46 minutes per year and 1 minute 26 seconds per day. 99.99% allows about 4 minutes 23 seconds per month and 52 minutes 34 seconds per year. To calculate it for any target, multiply the length of the period by one minus the uptime percentage: allowed downtime = period × (1 − uptime ÷ 100).

An availability target looks like a small number. The difference between 99.9% and 99.99% is a tenth of a percent, but it's the difference between 43 minutes of downtime a month and 4. One is enough time for an engineer to be paged, diagnose a problem and roll back a change. The other is barely enough time to open a laptop.

The calculator above converts any uptime percentage into allowed downtime, checks real downtime against an SLA, estimates what an outage costs and works out the availability of a service that depends on others. The rest of this page explains the math behind it, and the questions the percentage alone doesn't answer: which period it's measured over, what counts as downtime, what a breach costs, and how many incidents your budget can actually absorb.

How much downtime does each uptime percentage allow?

The table uses a 365-day year, an average month of 365 ÷ 12 days and a quarter of 365 ÷ 4 days. The two monthly columns differ because SLAs are usually written against calendar months, while SLO and error budget tools usually use a rolling 30-day window. Neither is wrong; the contract or the tool should say which one it uses.

The pattern to remember: each extra nine cuts the allowed downtime by a factor of ten. Two nines allow most of a working day per month; four nines allow less time than it takes to read this paragraph twice.

How to calculate uptime and downtime

Three formulas cover almost every SLA question. They all start from the number of minutes in the period:

1. Allowed downtime from an uptime target

Allowed downtime = period length × (1 − uptime ÷ 100)

Example: a 99.95% SLA measured over 30 days allows 43,200 × 0.0005 = 21.6 minutes.

2. Uptime percentage from actual downtime

Uptime % = (period length − downtime) ÷ period length × 100

Example: 1 hour 10 minutes of downtime in a 30-day month gives (43,200 − 70) ÷ 43,200 × 100 = 99.838%. That misses a 99.9% SLA.

3. Remaining budget against an SLA

Remaining budget = allowed downtime − downtime so far

Example: a 99.9% SLA over 30 days allows 43.2 minutes. After a 30-minute incident, 13.2 minutes are left for the rest of the month, about 31% of the budget.

The third formula is the most useful day to day, because it turns a percentage into a decision. The SRE term for this remaining allowance is the error budget: while it lasts, teams ship normally; when it runs low, they slow down risky changes.

What each level of uptime takes in practice

The percentage is a promise about how your team and systems behave under failure. Each level demands a different kind of operation:

The jump that catches most teams out is from 99.9% to 99.99%. Below four nines, a well-run on-call process can protect the budget. Above it, a single incident that waits for a human to wake up, acknowledge and diagnose has already used more than the whole month.

How many incidents fit in your downtime budget?

A downtime budget isn't spent on fixing problems alone. Every incident's duration is the sum of three stages, and the first two are often the largest:

Incident duration = time to detect + time to acknowledge + time to fix

Those are the averages teams track as MTTD, MTTA and the remainder of MTTR. Dividing the monthly budget by your typical incident duration shows how many incidents a target can absorb:

Budgets use an average month (219, 43.8, 21.9 and 4.4 minutes).

Three conclusions follow:

• A slow response can't hold 99.9%. One ordinary incident a month breaks it.

• Detection and acknowledgment are the cheapest minutes to save. Moving from 5-minute to 1-minute checks and from an inbox to on-call paging cuts incident length roughly in half without touching the fix itself.

• At 99.99%, people can't be in the loop for most incidents. Even a fast human response fits less than one incident every three months, which is why four nines depends on automatic failover.

The practical rule: before promising a target, multiply your current incident rate by your typical incident length, and compare it with the budget.

SLA vs SLO: set your internal target higher

The number you promise customers and the number you operate to shouldn't be the same.

The gap between the two is your safety margin. With an SLA of 99.9% and an SLO of 99.95%, the team starts slowing down risky changes when it has used about 22 minutes of downtime, long before the 43 minutes that would trigger customer credits.

Two rules make the gap work:

1. Alert on the SLO, report on the SLA. Burn-rate alerts on the internal target warn the team early; the SLA is only for the monthly report. Our error budget guide covers the burn-rate thresholds.

2. Never promise more than you've measured. Set the SLA below what your SLO history shows you can sustain in a bad month, not an average one.

The differences between the three terms are covered in detail in SLA vs SLO vs SLI.

The measurement window changes what the number means

The same percentage can be easy or hard to meet depending on the period it's measured over. Three choices matter.

Monthly, quarterly or yearly

A longer window pools downtime into one larger budget. At 99.9%, a yearly window allows 8 hours 46 minutes in total, so a single 8-hour outage in March still counts as meeting the SLA if the rest of the year is clean. Under a monthly window, the same outage is a breach of that month's 43-minute budget.

Calendar or rolling

A calendar window resets on the first of each month; a rolling window always looks at the last 30 days. SLAs are usually calendar-based, because credits are paid per billing period. SLOs are usually rolling, because a rolling window never resets the team's memory of last week's incident.

Around the clock or business hours

A business-hours SLA, for example Monday to Friday 09:00–18:00, covers 45 of the 168 hours in a week. That changes the budget a lot. At 99.9%, business hours in an average month total about 196 hours, so the allowance is roughly 11.7 minutes, a quarter of the 24×7 figure. Outages at night and over the weekend don't count at all.

Whichever you choose, name it in the agreement. "99.9%" without a window, a time zone and the hours it covers invites disputes.

What counts as downtime?

Most SLA disputes aren't about arithmetic. They're about which minutes count. Agree these points before you calculate anything:

The definitions behind each of these, including planned versus unplanned and full versus partial downtime, are in our guide to what downtime means. For keeping planned work from paging anyone without hiding real failures, see maintenance windows and alert suppression.

Service credits: what an SLA breach costs

When an SLA is missed, the usual remedy is a service credit: a discount on the next invoice, as a percentage of the monthly fee for the affected service. Credit schedules are tiered by how badly the target was missed. A common pattern for a 99.9% monthly SLA:

Credit terms vary widely, and the large cloud providers each publish their own schedules, so read the actual agreement rather than relying on a pattern. Three terms appear in almost every SLA:

• Credits must be claimed, usually within 30 days and with evidence, rather than applied automatically.

• Credits are capped, often at one month's fee for the affected service.

• Credits are the sole remedy, which means they replace, rather than add to, any claim for the customer's actual losses.

That last point is why credits rarely match the real cost of an outage. A customer paying $500 a month may receive a $50 credit for an outage that cost them thousands. For providers, the larger cost is usually trust: the renewals and expansions that a bad month puts at risk.

A sample SLA availability clause

Adapt the bracketed parts to your service. This is a starting point for discussion, not legal advice.

Availability commitment. [Provider] will make [Service] available at least [99.9]% of the time in each [calendar month], measured [24 hours a day, 7 days a week] in [UTC].

Calculation. Availability = (total minutes in the month − Downtime minutes) ÷ total minutes in the month × 100.

Downtime means any minute in which [the core user journey, for example login or the public API, fails or returns errors for more than [5]% of requests], as measured by [named monitoring source].

Exclusions. Downtime does not include scheduled maintenance announced at least [48 hours] in advance and limited to [4 hours] per month, or outages caused by the customer's own systems.

Service credits. If availability falls below the commitment, the customer may claim the credits in [Schedule A] within [30 days] of the end of the month. Credits are limited to [one month's fee] for the affected Service.

Composite availability: your SLA can't beat your dependencies

A request to your service usually passes through several others: a cloud region, a database, an identity provider, a payment API. The availability your users experience is lower than any single one of them.

Components in series

When every component must work for the service to work, multiply their availabilities:

A = A₁ × A₂ × … × Aₙ

Every component is at or above three nines, but the product is below 99.8%, roughly 18 hours of downtime a year. That's the ceiling: the best your service can do even if your own code never fails. Promising 99.9% on this stack means planning to breach.

Redundant components in parallel

When two independent copies can each serve the request, the service fails only when both fail at once:

A = 1 − (1 − A₁)ⁿ

Two independent 99.5% instances give 1 − 0.005² = 99.9975%. Redundancy is the main way to raise the ceiling, with one important condition: the copies must fail independently. Two replicas in the same zone, on the same network or receiving the same bad deployment are one failure, not two.

Raising the ceiling

• Make the weakest link redundant first. It raises the total the most; the calculator's composite tab shows which component that is.

• Shorten the chain. Every synchronous dependency removed from the critical path raises the ceiling more than upgrading one.

• Degrade gracefully. If the recommendations service is down, show the page without recommendations. A dependency that can fail without failing the request no longer counts in series.

• Promise below the ceiling. Set the SLA to what the stack can hold in a bad month, with margin for your own failures.

How to calculate the cost of downtime

The calculator's cost tab adds up the three parts that can be measured for a single outage:

Cost = lost revenue + people cost + SLA credits and other direct costs

• Lost revenue = revenue per hour through the affected service × share of it actually lost × hours of downtime. The share is rarely 100%: some customers retry later, and a partial outage affects only some of them.

• People cost = number of people working on the incident × their hourly cost × hours. Include everyone pulled in: on-call engineers, the incident commander, support and communications.

• SLA credits and other direct costs, such as overtime, emergency capacity or contractual penalties.

Example: a 45-minute outage of a checkout service that normally handles $12,000 an hour, with 60% of that revenue lost, five people involved at $90 an hour and $2,000 in credits: $5,400 + $338 + $2,000 ≈ $7,738, or about $172 per minute.

The real figure is usually higher, because churn, delayed work and damage to reputation don't appear on any single invoice. Industry surveys show how high it can go: in the Uptime Institute's 2026 outage analysis, more than half of operators said their most recent significant outage cost over $100,000

The cost scales with minutes, so the cheapest reduction is usually the time before anyone starts working: faster detection, alerts that reach the right on-call engineer the first time, and automatic escalation when nobody acknowledges.

Sources

• Google SRE Book: Embracing Risk

• Google SRE Workbook: Implementing SLOs

• Uptime Institute, Annual Outage Analysis 2026