Uptime percentage:
how many minutes of downtime each nine allows

What a string of nines promises

An availability figure answers one question: out of all the minutes in a period, what share of them was the service actually working? A provider that promises 99.9% is saying it will be up for 999 minutes in every 1,000, and that the missing minute is its allowance for trouble.

Because the promise is a percentage of a long period, the same number sounds generous or strict depending on how you convert it. 99% looks close to perfect on a slide, yet it permits more than seven hours of outage every month. Turning the percentage into time is the habit worth building.

Teams usually quote availability over a calendar month or a rolling 30 days for contracts, and over a year for internal targets. Always check which window an agreement uses, because one long outage in a short window can break the promise even if the yearly figure looks healthy.

Converting uptime into allowed downtime

The same arithmetic works backwards. If a service was down for 95 minutes in a 30-day month, availability was (43,200 − 95) ÷ 43,200, which is about 99.78%.

Seconds matter at the top end. A 99.99% promise is under five minutes a month, which is shorter than the time most people need to notice an alert, log in and start diagnosing. Targets of that level are met by systems that detect and repair faults automatically, not by people reacting.

Downtime allowed at common targets

The table uses a 30-day month and a 365-day year. A calendar month of 31 days allows slightly more, and a leap year adds a day.

Why a stack of services is less available than each part

A web app rarely depends on one thing. A request might pass through DNS, a load balancer, an application server and a database, and all must be up at once. When the parts fail independently, the availabilities multiply.

Redundancy works in the opposite direction. Two independent copies where either one can serve traffic fail together only when both are down, so the unavailabilities multiply instead.

Independence is the catch. Two servers in the same rack, on the same power feed or running the same buggy release will often fail together, and the real figure lands well below the formula.

Dependencies you do not control count too. If your product relies on a payment gateway, an SMS provider or a cloud region, its availability multiplies into yours, so your own promise cannot sensibly exceed the product of the services beneath it unless you design around their failures.

Choosing a target that fits the business

Each additional nine usually costs far more than the last. Moving from 99% to 99.9% may mean a second server and a decent deployment process. Going from 99.9% to 99.99% tends to need multi-zone design, automated failover, careful change control and an on-call rota that responds in minutes. Past that, you are into multi-region work and a large engineering budget.

A useful way to choose is to price an hour of downtime. If an hour offline costs a shop ₹15,000 in lost orders, then 43 minutes a month (99.9%) is about ₹10,800 a month in expected loss, and spending more than that to remove it needs another reason, such as reputation. If an hour costs ₹15 lakh, the maths points to a much tighter figure.

Targets are promises you must be able to keep, so base them on what you have measured over several months, not on what looks tidy.

One long outage versus many short ones

The percentage treats a single 40-minute outage and forty one-minute blips as identical, but users do not. Brief interruptions are often hidden by retries, while a long outage shows up in the news and in support tickets. Some contracts therefore add a second clause that limits the length of any one incident, or count only outages longer than a few minutes.

Also watch how the measurement is sampled. A probe that checks once every five minutes can miss a three-minute outage altogether, and a probe that checks every second will count each one. When you compare your own figure with a vendor's, make sure the checks are similar in frequency and location.

Measuring your own availability honestly

• Define what counts as up. A page that loads but returns errors for logged-in users is down for those users.
• Probe from outside your network, from more than one location, so that a regional fault shows up.
• Count partial outages by the fraction of requests affected if your tooling can, rather than all or nothing.
• Keep the raw outage log. Averaging a good quarter with a bad one hides the incident customers remember.
• Set the internal target tighter than the contractual one, so that you have room to act before a penalty clause applies.