Uptime and SLA calculator

How much downtime an availability level allows per year, month or week, the reverse calculation from a real outage, and the availability of a whole infrastructure, link by link.

The calculation runs in your browser: nothing you type is sent anywhere.

Downtime allowed by an availability level

Your parameters

%

SLA commitment or measured availability.

Common values

Result

Per year

8 h 45 min

99.9%

Per month

43 min

Per year8 h 45 min
Per quarter2 h 11 min
Per month43 min
Per week10 min
Per day1 min 26 s
Number of nines3.00

−log₁₀(1 − availability)

Reverse calculation: from downtime to availability

Your parameters

h
min

Result

Matching availability

99.452%

4 h of downtime over the period

Availability of a chain of components

Your parameters

Example components and values: replace them with yours.

%
%
%

Redundant instances: one working instance is enough.

Result

Chain availability

99.848%

Matching yearly downtime

13 h 21 min

Assumption: component failures are independent and failover to a redundant instance is instantaneous. Two servers on the same power feed, in the same datacenter or run by the same hands are not independent: the result is then a ceiling, not a forecast.

How the calculation works

Allowed downtime is the share of the period that the availability level leaves out. The calculator uses a 365-day year, a month equal to one twelfth of a year (30.4 days) and a quarter equal to a quarter of a year:

allowed downtime = (1 − availability) × length of period
availability     = 1 − downtime ÷ length of period
number of nines  = −log₁₀(1 − availability)

In an infrastructure, every essential component multiplies its availability by the others': a series chain. A redundant component, on the other hand, is only down when all its instances are down at the same time:

series       : A = a₁ × a₂ × … × aₙ
k instances  : a = 1 − (1 − a_instance)^k
example      : 99.95% × (1 − 0.005²) × 99.9% = 99.848%

The pre-filled example, network access at 99.95%, two application servers at 99.5% and a database at 99.9%, gives 99.848%, about 13 h 21 min of downtime per year. Doubling the application servers almost erased their share: the link that now matters is the database, on its own.

These formulas assume independent failures and instant failover. Correlated failures break them: same power feed, same datacenter, same hypervisor, same update rolled out everywhere, same human mistake. And a failover that needs someone to act counts detection and response time as downtime. The result is a ceiling, not a promise.

What an SLA does not tell you

An availability figure is only as good as its definition: where it is measured, over which period, with which exclusions (planned maintenance, external causes), and what happens when it is missed. Our guide to SLA, SLO and SLI separates the contract you sign, the target you aim for and the metric you actually measure.

The calculation gives minutes; what they cost is another question. The downtime cost calculator turns those hours into money from your revenue, headcount and reliance on IT. And a night-time outage lasts until someone sees it and acts: that is what 24/7 IT on-call support is for.

After the calculation

Gaining a nine means removing a single point of failure. The four architectures on our managed high availability page range from restarting a VM to failing over a service, from four hours down to ten seconds depending on the setup. For a service that must survive losing a server, a Keepalived or Pacemaker service cluster moves a floating IP from one node to the other; the two-layer high availability design combines a service cluster with hypervisor high availability; internal multi-site anycast places the same service, behind the same IP, in every site.

Correlated failures are fought by separating what can fail together. Our multi-ASN DNS infrastructure is one example: four servers on four distinct networks, so that no single operator can make our domains unreachable on its own. Choosing your own interconnections and transit providers is also what our autonomous network AS206014 allows.

Availability measures how often and how long you are down, not what you lose when you have to restore. For data loss and restore time, move on to the RPO / RTO calculator.

Frequently asked questions

How much downtime does a 99.9% SLA allow?

8 h 45 min 36 s per year, which is 43 min 48 s per month and about 10 minutes per week, based on a 365-day year and a month equal to one twelfth of a year. At 99.99%, only 52 min 34 s per year remain, and 4 min 23 s per month.

How do I calculate availability from an outage duration?

Availability = 1 − (downtime ÷ length of the period). Four hours of downtime over a 30.4-day month gives 99.45%; one hour of downtime over a year gives 99.989%. The reference period changes everything: the same outage weighs twelve times more in a monthly SLA than in a yearly one.

Three components at 99.9% in series: what is the total availability?

99.9% × 99.9% × 99.9% = 99.70%, or about 26 h 15 min of downtime per year instead of 8 h 45 min for a single component. Every essential link adds its outages to the others: a chain is always less available than its weakest link.

Is doubling a 99% server enough to reach 99.99%?

On paper, yes: 1 − (1 − 0.99)² = 99.99%, or 52 min 34 s of downtime per year. In practice, only if the two servers fail independently of each other and failover is automatic. Two servers on the same power feed, in the same datacenter or updated at the same time often fail together.

What does "number of nines" mean?

It is the count of 9s in the availability figure: 99.9% is three nines, 99.999% is five. It is computed as −log₁₀(1 − availability), which also gives in-between values: 99.95% is 3.3 nines. Each extra nine divides the allowed downtime by ten.

Contact

Address

5 B RUE DES NOYERS, 95300 PONTOISE, FRANCE

Let's Talk About Your Project

15 minutes to understand your needs, no commitment.

Book a Slot