Uptime and downtime calculator

What availability and the nines mean

Availability is the share of a period during which a service works. AWS defines it as the time a workload is available for use divided by the total time, usually over a month or a year; Google’s SRE Book counts successful requests instead of minutes for services spread over the globe. The nines are shorthand: Google’s SRE Book calls 99% “2 nines” and 99.999% “5 nines”, and the published Compute Engine target of 99.95% “three and a half nines”. Each extra nine divides the allowed downtime by ten (the book: an order of magnitude improvement toward 100%), which is why the jump from 99.9% to 99.99% is far harder than the jump from 99% to 99.9%. This calculator turns a percentage into time, in both directions, and adds the arithmetic for components that depend on each other or back each other up.

The formula

Allowed downtime = (1 − availability) × period. For 99.9% over a 365-day year, 0.001 × 31,536,000 s = 31,536 s. Measured availability is the reverse, (period − downtime) ÷ period. Components in series, where every one must work, multiply: A = A₁ × A₂ × … Redundant independent components, where one working is enough, fail only together: A = 1 − (1 − A₁) × (1 − A₂) × … The MTBF estimate is MTBF ÷ (MTBF + MTTR). The only input that is a convention is the length of the year and the month, so the calculator lets you choose.

The nines in time

The figures agree with the availability table in Appendix A of Google’s SRE Book (for example 8.76 hours a year and 43.2 minutes a month at 99.9%) and with AWS’s yearly table, which cuts the seconds off (“8 hours 45 minutes”, “52 minutes”, “5 minutes”). Neither source states its year and month lengths. Google’s numbers match a 365-day year and a 30-day month exactly, which is what the calculator uses unless you change it; AWS’s truncated figures would fit 365.25 days as well.

Worked example: a 99.95% service

The target allows 21 min 36 s in a 30-day month and 4 h 22 min 48 s in a year. A single 15-minute outage uses 69% of the month’s budget. Put the same service behind two other components that are each 99.95% and are all needed, and the chain delivers 99.850075%, which is 13 h 8 min 0.35 s a year, not 4 h 22 min 48 s. Running a 99.9% component as two independent copies, either of which is enough, gives 99.9999% (AWS’s example).

Limits of this arithmetic

Definitions differ: AWS advises against excluding scheduled maintenance from the total time, while Google’s book focuses on unplanned downtime for its objectives, so say which one your number uses. Time-based and request-based availability are not the same: a service that is up but answering a tenth of requests with errors is not 100% available by the request measure. The redundancy formula assumes failures are independent, and two copies in one data center or sharing one deployment are not. A component’s availability on paper is a design goal, not a guarantee; for components that publish nothing, AWS suggests the MTBF and MTTR estimate. Use this as planning arithmetic for a service level objective, not as a contract.

How much downtime is 99.9% availability?

In a 365-day year, 99.9% allows 8 h 45 min 36 s of downtime, since 0.1% of 31,536,000 seconds is 31,536 seconds. In a 30-day month it is 43 min 12 s, and in a day 1 min 26.4 s. Google’s SRE Book availability table gives the same figures (8.76 hours a year, 43.2 minutes a month, 1.44 minutes a day), and AWS lists “8 hours 45 minutes” a year. The 57.6 seconds you sometimes see after the 45 minutes belong to a 365.25-day year: 8 h 45 min 57.6 s.

What do four nines and five nines mean in minutes?

Four nines, 99.99%, allows 52 min 33.6 s a year, 4 min 19.2 s a month and 8.64 s a day (Google’s book says 52.56 minutes a year). Five nines, 99.999%, allows 5 min 15.36 s a year, 25.92 s a month and 0.864 s a day. The nines are counted from the unavailability: 3 for 99.9% and 3.3 for 99.95% on a strict logarithmic count. Google’s book notes that each additional nine is an order of magnitude improvement toward 100%, and uses looser phrases such as “three and a half nines” for targets in between; the book gives 99.95% as that figure for the published Compute Engine target.

How do I calculate availability from downtime?

Availability = (total time − downtime) ÷ total time, as AWS defines it: the time a workload is available for use over the total time. One hour of downtime in a 30-day month (720 hours) is 719 ÷ 720 = 99.861111%. Choose the period before you compare, because the same outage costs more of a day’s budget than of a year’s. If you count requests rather than minutes, availability is successful requests ÷ valid requests, which is how Google’s SRE Book defines it for globally distributed services.

What happens to availability when components are chained or duplicated?

If every component is needed (a hard dependency), multiply the availabilities. AWS’s example is three components of 99.99% each: 99.99% × 99.99% × 99.99% ≈ 99.970003%. Five components of 99.9% give 99.500999%, 1 d 19 h 42 min 44.96 s of downtime a year. If any one of independent redundant components is enough, subtract the product of the failure rates from 100%: AWS’s example is two components of 99.9%, which give 100% − (0.1% × 0.1%) = 99.9999%. The result is only as good as the independence assumption; shared power, one bad deployment or a common dependency breaks it.

What is an error budget?

The error budget is the amount of unreliability the service is allowed, the gap between its availability target and 100%. Google’s SRE Book (chapter 3, “Embracing Risk”) has the SRE and product teams agree a quarterly error budget based on the service level objective: a clear, objective metric of how unreliable the service may be within the quarter. A 99.999% objective leaves a 0.001% failure rate; a problem that fails 0.0002% of the quarter’s expected queries spends 20% of that budget, and while budget remains, new releases can be pushed. For a request-based target the budget is a count of failed requests: the book’s example of 2.5 million requests a day at 99.99% allows 250 errors. In time, a 99.99% target leaves 8.64 s a day and 12 min 57.6 s a 90-day quarter.

Should I use 365 or 365.25 days, and a 30-day month?

Pick one convention and state it. Google’s availability table is consistent with a 365-day year, a 90-day quarter and a 30-day month (its 90% row gives 36.5 days a year and 3 days a month). A Julian year is 365.25 days and the Gregorian calendar year averages 365.2425; the calculator offers 365 and 365.25 for the year, and 30 days or one twelfth of the year for the month. The difference is about 21.6 seconds a year at 99.9%, so it matters only when you quote seconds.

How do I get availability from MTBF and MTTR?

AWS gives an estimate for components that publish no availability: MTBF ÷ (MTBF + MTTR), where MTBF is the mean time between failures and MTTR the mean time to recover, in the same unit. With an MTBF of 150 days (3,600 hours) and an MTTR of 1 hour the estimate is 3,600 ÷ 3,601 = 99.97223%. It treats failures as a steady rhythm, so it is a rough guide rather than a measurement.

Sources: Google, Site Reliability Engineering, chapter 3 “Embracing Risk” (availability as request success rate, error budget), chapter 4 “Service Level Objectives” (nines notation) and Appendix A “Availability Table” (sre.google/sre-book); AWS Well-Architected Framework, Reliability Pillar, “Availability” (formulas, yearly table, hard dependencies, redundant components, MTBF and MTTR). Related: percentage calculator, time calculator, time to decimal calculator for converting hours and minutes, probability calculator for the independent-events arithmetic behind series and parallel systems, and RAID calculator.