What an Availability Percentage Actually Allows

The window decides more than the nine does

An availability figure is a fraction of a period, and the period is not part of the number. Take 99.9 % three ways: over a year it allows 525.60 minutes of downtime, over a month 43.20, over a day 1.44. Those are the same percentage. An outage of four hours breaches a monthly 99.9 % five times over and passes an annual 99.9 % with three hundred minutes still in hand. When someone quotes you a target without a window, they have told you almost nothing.

This tool has no window control at all. The four boxes across the top convert one target into four periods, which is useful, but the reverse box underneath — the one that turns an observed outage back into a percentage — always divides by the same thirty-day month. If your contract is measured quarterly, or over a rolling twenty-eight days, or per calendar month, that box is answering a different question from the one you asked. It is still the right arithmetic; it is just applied to a period you did not choose.

The thirty-day month is a defensible simplification and the tool says so in its own note. What it does not say is that the same tool slug carries a second definition: the fallback calculation registered alongside the component uses a month of 43,800 minutes, which is 30.42 days, while the component itself uses 43,200 minutes. At 99.9 % that is 43.80 minutes against 43.20 — the same tool, two months, a gap of 36 seconds. Neither is wrong as an average; they simply are not the same average.

February is not thirty days, and the reverse box does not know

Vendors bill by the month they actually have. Amazon defines the Monthly Uptime Percentage for EC2 as 100 % minus the percentage of minutes during the month in which the service was in a state of Unavailability, over a monthly billing cycle — a real month, from 28 days to 31. At 99.9 %, a 28-day February allows 40.32 minutes, the tool's 30-day month allows 43.20, and a 31-day March allows 44.64. So the reverse box is 2.88 minutes too generous in February and 1.44 minutes too strict in March. That is small until an incident lands within three minutes of a threshold, which is exactly when someone opens a calculator.

The same contract also tells you what happens when the number is missed, and it is rarely what people expect. Amazon commits to 99.99 % monthly uptime for instances deployed across multiple availability zones and 99.5 % for an individual instance, and the remedy is a service credit against the bill: 10 % of the charges between 99.0 % and the commitment, 30 % between 95.0 % and 99.0 %, and 100 % below 95.0 %. A credit is not compensation for what an outage cost you, and no amount of arithmetic on this page changes that.

Each nine costs ten times more and buys ten times less

The chart on the page is drawn on a logarithmic scale for a reason: on a linear one, 99 % and 99.999 % cannot both be visible, because they differ by a factor of ten thousand. Per month the tool gives 7 h 12 min at 99 %, 43 min 12 s at 99.9 %, 4 min 19 s at 99.99 % and 26 s at 99.999 %. Read that as an engineering ladder rather than a marketing one. The step from three nines to four buys back about eight hours a year, and those eight hours are bought with failover you now have to build, test and keep tested.

The duration format hides the tail. It prints only the two most significant non-zero units, so 99 % over a year shows as 3 d 15 h where the true budget is 3 d 15 h 36 min, and 99.5 % shows as 1 d 19 h where it is 1 d 19 h 48 min. At the fine end the rounding goes the other way: the daily budget at 99.999 % is 0.86 seconds and the box reads 1 s, because the formatter rounds to whole seconds before it formats. Neither is a calculation error, and both are worth knowing before you paste a figure into a runbook.

Time up is not the same as requests served

This calculator measures availability in time, which is the definition contracts use because it is the one a clock can settle. Google's SRE book points out the limit of it: for a service that can be partly available, or whose load varies through the day, an aggregate measure — successful requests divided by total requests — is more practical than counting minutes, because ten minutes of half the traffic failing at midday is not the same event as ten minutes of nothing failing at four in the morning. A time-based figure cannot tell those apart, and neither can this page.

Two more behaviours are worth knowing before you rely on the reverse box. A target of 100 % is accepted and produces a budget of 0 s, so a single minute of downtime returns 99.9977 % and the verdict Below target — arithmetically correct and a good illustration of why nobody writes 100 % into a contract. And a target outside 0 to 100 replaces the whole result block with a one-line range message rather than showing a wrong number, which is the right behaviour and rarer than it should be.

Frequently asked questions

Is 99.9 % measured monthly the same promise as 99.9 % measured yearly?

No, and the difference is a factor of 12.17. Measured over a year, 99.9 % allows 525.60 minutes of downtime; measured over a 30-day month it allows 43.20. A single four-hour incident sits comfortably inside the annual promise and blows through the monthly one. The annual window is the more generous of the two, which is the opposite of how it is usually assumed to work, and it is also the one that lets a provider absorb one very bad day and still report a clean year. If you are choosing between two offers, compare the windows before you compare the nines.

Why does the page already say Below target when it loads?

Because both boxes ship pre-filled, and the two defaults contradict each other on purpose. The target starts at 99.9 %, which allows 43 min 12 s in a 30-day month, and the observed-downtime box starts at 51 minutes, which works out to 99.8819 %. Eight minutes over budget is a realistic-looking miss rather than a catastrophe, so the page opens on the situation people actually arrive with: the morning after, wanting to know whether the number they have breaches the number they promised. Change either field and the verdict updates.

How long is a month, as far as this tool is concerned?

Thirty days on the screen, and 30.42 days in the fallback calculation registered under the same tool name. The component you interact with uses 43,200 minutes; the declarative calculation that stands behind the same slug uses 43,800. At 99.9 % those give 43.20 and 43.80 minutes, a gap of 36 seconds, and at 99 % they give 432 and 438. The year is 365 days in both, and the day 86,400 seconds in both, so the month is the only place they part company. Use the 30-day figure if you are reasoning about a fixed window, and your provider's own calendar month if you are arguing about a bill.

My provider promises 99.99 %. Is that four minutes of downtime?

Four minutes and nineteen seconds a month, or fifty-two minutes and thirty-four seconds a year, if the window is the one you assume. But read the contract for three things before you plan around it. First, what counts as unavailable — many agreements only count a total loss of external connectivity, so a service that is answering slowly, or failing one request in ten, may be up by the definition that matters. Second, what is excluded: scheduled maintenance, your own configuration, anything upstream. Third, what happens when it is missed: with Amazon EC2 the remedy is a service credit of 10, 30 or 100 % of the charges for the affected resources, and you have to claim it.

Should I measure availability in minutes or in failed requests?

Both, for different audiences. Time is what a contract can enforce, because a clock settles the argument and this calculator works in exactly that currency. But Google's SRE book argues that for services which can be partly available, or whose traffic is uneven through the day, an aggregate figure — successful requests over total requests — describes the user experience better. The two can disagree sharply: a five-minute outage during your busiest hour and a five-minute outage at three in the morning are identical in minutes and very different in failed requests. Report the aggregate to your team and the time-based figure to your customer, and never let one be quietly substituted for the other.