SLA Uptime & Downtime Calculator

Enter an uptime target, choose the period it is measured over, and add the downtime you have had if you want to check it. The calculator returns the downtime the target allows in that period, the uptime actually achieved, how much of the downtime budget is left or how far it was overrun, and the number of nines in the target. The table shows the same target over every standard period. With the defaults, a 99.9% target over a 30-day month allows 43 min 12 s of downtime, and a 20-minute outage leaves the month at 99.954% with 23 min 12 s of budget to spare.

Where the nines come from

Availability is the share of time a system does its job, and engineers have measured it for as long as computers have been unreliable enough to need the measure. In their 1991 survey "High-Availability Computer Systems" for IEEE Computer, Jim Gray and Daniel Siewiorek recalled that machines built in the late 1950s failed about every twelve hours and took about eight hours to repair, a cycle that gave 60% availability. They quantified it as mean time to failure divided by the sum of mean time to failure and mean time to repair. By 1980 a well-run system reached 99%, which they noted still meant about 100 minutes of downtime a week; this calculator puts 99% of a week at 1 h 40 min 48 s.

The same paper gave the industry its shorthand. As the nines piled up, Gray and Siewiorek argued, it was clearer to think in minutes of outage per year, and clearer still to define an availability class: the number of leading nines in the availability figure, by analogy with the classes of a cleanroom. Their table ran from unmanaged systems at 90%, class 1, through well-managed ones at 99.9%, class 3, to ultra-available systems at 99.99999%, class 7. They held up the telephone network as the class 5 example, with a design goal of at most two hours of outage in forty years, about 99.9994%. Philip C. Richards, one of the designers of the Bell System's No. 2 electronic switching system, recalls the same two-hours-in-forty-years objective in a first-hand account on the Engineering and Technology History Wiki.

From promises to contracts

Uptime became a contract term when computing became a rented service. Amazon Web Services put Amazon S3 under a service level agreement from 1 October 2007, as Jeff Barr announced on the AWS blog that month: 99.9% uptime measured monthly, with a credit of 10% of the month's charges below that and 25% below 99%. Amazon EC2 followed on 23 October 2008, when it left beta with a commitment of 99.95% availability within a Region. EC2's current agreement, last updated on 25 May 2022, promises 99.99% per Region, computed as 100% minus the percentage of minutes in the month that the Region was unavailable, with credits of 10% below 99.99%, 30% below 99% and 100% below 95%. S3 now computes its monthly figure as 100% minus the average error rate across five-minute intervals.

Google's 2016 book Site Reliability Engineering turned the same arithmetic into a way of running teams. Its chapter on embracing risk notes that a 99.99% target allows 52.56 minutes of downtime in a year, which this calculator shows as 52 min 33.6 s for 365 days. It describes a quarterly error budget set by the service level objective: while measured uptime stays above the objective, new releases can ship, and when outages use up the budget, releases pause. The 2018 Site Reliability Workbook recommends a four-week rolling window as a good general-purpose measurement period, which is why 28 days is one of the options here.

How the calculation works

The downtime budget is the share of the period that the target leaves unavailable:

allowed downtime = (100 − uptime target) ÷ 100 × period length

For the defaults, a 30-day month is 30 × 86,400 = 2,592,000 seconds, and 99.9% leaves 0.1% of it: 2,592 seconds, or 43 min 12 s. Measured downtime runs the formula the other way:

uptime achieved = (period length − downtime) ÷ period length × 100

Twenty minutes of downtime in a 43,200-minute month gives (43,200 − 20) ÷ 43,200 × 100 = 99.954%, and the budget left is 43 min 12 s minus 20 min, or 23 min 12 s. When downtime exceeds the budget, the result says by how much, and the uptime figure carries enough decimals to fall visibly below the target instead of rounding up to it. An outage of 43 min 12.006 s, 6 ms over the budget, shows as 99.8999998%.

The number of nines is counted from the digits of the target, so 99.95% has three and 99.99% has four. Counting digits avoids a floating-point trap: 100 − 99.99 is not exactly 0.01 in binary, and a count based on the logarithm of the downtime share would call 99.99% three nines.

Why the length of the month matters

Many uptime tables use an average month of 30.44 days, a twelfth of a 365.25-day year, and report 43 min 49.8 s, usually rounded to 43 min 50 s, for 99.9%. No billing month is that long. Agreements like EC2's count the minutes in the calendar month, so the budget moves with the calendar: 40 min 19.2 s in a 28-day February, 43 min 12 s in a 30-day month and 44 min 38.4 s in a 31-day month.

The difference decides real cases. A single 42-minute outage against a 99.9% monthly target passes in a 31-day month, at 99.906% with 2 min 38.4 s to spare, and in a 30-day month, at 99.903% with 1 min 12 s to spare. In February it breaches the target: 99.896%, 1 min 40.8 s over. Leap years shift annual budgets the same way, since 366 days at 99.9% allow 8 h 47 min 2 s against 8 h 45 min 36 s for 365. Use the custom period for a leap year, a 29-day February or a quarter of 91 or 92 days.

Counting nines

Each extra nine divides the budget by ten:

At two nines a month can absorb a bad deploy and a slow rollback. At three, the 43 min 12 s budget covers roughly one incident that is caught and fixed quickly. At four, 4 min 19.2 s a month is too short for someone to be paged, investigate and act, so recovery has to be automatic. At five, 25.92 s a month leaves room only for failover that completes in seconds. That is the practical meaning of Gray and Siewiorek's classes: each one asks for a different way of operating, not just more care.

Dependencies, redundancy and what counts as down

A service is rarely more available than the things it depends on. The reliability pillar of AWS's Well-Architected Framework multiplies the availabilities of hard dependencies: a service designed for 99.99% that relies on two other independent services at 99.99% can reach about 99.97%, which allows 12 min 57.6 s in a 30-day month instead of 4 min 19.2 s. Redundancy works the other way, because independent copies must fail at the same time: two components at 99.9% give 100% − 0.1% × 0.1% = 99.9999%, or 2.59 s in 30 days. Both figures assume failures are independent, an assumption that shared networks, deployments and regions often break. The same guidance estimates availability from reliability data as mean time between failures divided by the sum of that and mean time to recover: a component that fails every 150 days and takes an hour to recover runs at about 99.97%.

Definitions matter as much as arithmetic. AWS advises against leaving planned maintenance out of the total time, since users still want the service then, though some agreements exclude it. Some agreements count only full outages, others count error rates, as S3 does, and partial degradation may or may not count as downtime. Before relying on a figure here, check how your agreement defines downtime, the measurement period and the process for claiming credits.

These figures follow the arithmetic of uptime percentages; an agreement's own definitions, exclusions and credit terms decide what you are owed. See the site disclaimer.

Frequently asked questions

How much downtime does 99.9% uptime allow?

0.1% of the period: 43 min 12 s in a 30-day month, 44 min 38.4 s in a 31-day month and 40 min 19.2 s in a 28-day February. Over a 365-day year that adds up to 8 h 45 min 36 s, and over a single day to 1 min 26.4 s.

Why do some uptime tables show 43 minutes 50 seconds a month for 99.9%?

They use an average month of 30.44 days, a twelfth of a 365.25-day year, which gives 43 min 49.8 s. No billing month is that long. Agreements such as Amazon EC2's count the minutes in the actual month, so the real budget is 40 min 19.2 s in February, 43 min 12 s in a 30-day month and 44 min 38.4 s in a 31-day month.

What does five nines mean?

99.999% availability. It allows 5 min 15.4 s of downtime in a 365-day year, 25.92 s in a 30-day month and 864 ms in a day. Jim Gray and Daniel Siewiorek's 1991 survey of high-availability systems called this class 5, the class of the telephone network.

How do I calculate uptime percentage from downtime?

Subtract the downtime from the length of the period, divide by the period and multiply by 100. Twenty minutes down in a 30-day month of 43,200 minutes gives (43,200 − 20) ÷ 43,200 × 100 = 99.954%, inside a 99.9% target with 23 min 12 s of budget to spare.

Is 99.95% three and a half nines?

It is sometimes called that, but it has three leading nines, so it counts as three. It allows half the downtime of 99.9%: 21 min 36 s in a 30-day month and 4 h 22 min 48 s in a 365-day year. A fourth nine cuts the budget to 4 min 19.2 s a month.

How do dependencies affect an SLA?

Hard dependencies multiply. A service at 99.99% that relies on two other independent services at 99.99% can reach about 99.97%, which allows 12 min 57.6 s in a 30-day month instead of 4 min 19.2 s. Redundancy works the other way: two independent components at 99.9% are both down only 0.1% × 0.1% of the time, which is 99.9999%.

Sources

1. High Availability Computer Systems (draft of the IEEE Computer article), Jim Gray and Daniel P. Siewiorek, 1991
2. First-Hand: Events in Telecommunications Switching Development: No. 2 ESS and ITT System 12, Philip C. Richards, Engineering and Technology History Wiki
3. Amazon S3 At Your Service, Jeff Barr, AWS News Blog, 2007
4. Amazon Compute Service Level Agreement, Amazon Web Services, 2022
5. Embracing Risk (Site Reliability Engineering), Google
6. Implementing SLOs (The Site Reliability Workbook), Google
7. Availability (Reliability Pillar, AWS Well-Architected Framework), Amazon Web Services