Uptime and SLA Calculator

How much downtime 99.9% uptime allows

99.9% uptime ("three nines") allows 8 hours 45 minutes 57 seconds of downtime a year, which is 43 minutes 49 seconds a month or 1 minute 26 seconds a day. Each extra nine divides the allowance by ten: 99.99% allows 52 minutes 35 seconds a year, and 99.999% about 5 minutes 15 seconds.

The allowance is simply the period multiplied by the unavailable fraction. For 99.9% that fraction is 0.1%, so a 30.44-day month of 2,629,800 seconds allows 2,629.8 seconds of downtime.

How the periods are defined

A year here is 365.25 days, the average including leap years. A month is a twelfth of that, 30.4375 days (shown as 30.44), and a quarter is a quarter of the year. Contracts sometimes use a 30-day month or the actual calendar month, which shifts the figures slightly: 99.9% of a 30-day month is 43 minutes 12 seconds, and of a 31-day month 44 minutes 38 seconds. Check which one your SLA uses.

Every figure is rounded down, so the allowance is never overstated, and the arithmetic is done in exact decimal fractions rather than floating point, so 99.99 never turns into 99.99000000000001.

Working back from an outage

To see what an outage did to a target, take the downtime away from the period and divide: a 2-hour outage in a 30.44-day month leaves (730.5 − 2) / 730.5 = 99.726% availability, which misses 99.9%. Enter durations as 43m 49s, 1h 30m, 1.5 hours or 01:30:00.

Combining components

A request that passes through several parts in a row only succeeds if all of them work, so their availabilities multiply. An app server at 99.9% behind a load balancer at 99.99% and in front of a database at 99.95% is at best 99.9 × 99.99 × 99.95 = 99.84%, lower than any one part.

Redundant parts work the other way: the system fails only when every copy fails at once, so you multiply the unavailabilities. Two independent servers at 99% each give 1 − (0.01 × 0.01) = 99.99%.

Series:    A = A1 × A2 × … × An
Parallel:  A = 1 − (1 − A1) × (1 − A2) × … × (1 − An)

Both formulas assume failures are independent. Two servers in the same rack, on the same power feed, or running the same bad deploy fail together, so real redundancy is usually worth less than the formula says.

Measuring what you actually get

An SLA is only as good as the measurement behind it. An external check every minute misses outages shorter than a minute and counts a single failed probe as a full minute down, so decide in advance how often you probe, from where, and how many consecutive failures count as an outage. On the server itself, a process manager that restarts a crashed app turns a crash into seconds of downtime:

pm2 start app.js --name api
pm2 save && pm2 startup

Common mistakes

• Promising a target you cannot measure. Below one minute a month (99.998% and above) most monitoring cannot tell you whether you met it.
• Forgetting planned maintenance. Unless the SLA excludes it, a 30-minute maintenance window is more than a 99.95% month allows (21 minutes 54 seconds).
• Counting only the server. DNS, the TLS certificate and the network in front of the server are in series with it.

Keeping releases out of the downtime budget

A bad deploy is a common cause of downtime. Shipown keeps release directories and attempts to restore the previous release when it detects a runtime failure, and its live updates feed reports an app going down or a server stopping answering while the desktop app is running.