Skip to main content
DevOps Insightsguides & answers

Interactive tool

What your parts add up to

Three components at 99.9% in a row are not 99.9% together, and two replicas at 99% are not simply 99%. This multiplies it out, shows every step, and says what the arithmetic assumes.

Runs in your browser · nothing is sent anywhere

Tiers, in the order a request passes through them

Every tier must work for the system to work. Within a tier, enter how many identical components there are and how many must be up.

Tier 1
Tier 2
Tier 3
System availability
99.8825%
Down per year
10 hours
Down per 30 days
51 minutes

Database accounts for about 85% of the expected downtime. Improving any other tier changes the total very little until this one improves.

The working

  1. Load balancer: a = 0.9999 = 99.99%
  2. App servers: Σ C(3,i) · a^i · (1 − a)^(3−i), i = 2…3, with a = 0.995 = 99.992525%
  3. Database: a = 0.999 = 99.9%
  4. System: 99.99% × 99.992525% × 99.9% = 99.8825%
  5. Downtime: (1 − A) × 525,600 minutes a year = 10 hours

What this assumes

  • Components fail independently. Replicas in one zone, on one deploy or sharing one config fail together, and the real figure is then closer to a single component's.
  • Failover is instant and always works. Detection time and a failover that itself fails both add downtime this leaves out.
  • Each percentage is measured, long-run availability. A provider's SLA is the level below which it owes service credits: a contract, not a measurement of what you will get.

What availability adds up to

A request usually passes through several things in a row: a load balancer, an application, a database. It succeeds only if every one of them is working, so the chances multiply. Three parts that are each up 99.9% of the time are up together only about 99.7% of the time, roughly 26 hours of downtime a year instead of 9.

Copies work the other way. If two identical servers can each do the job, the service fails only when both are down at once. Two copies at 99% each give 99.99%, as long as they fail independently.

Using it

Add one tier for each thing a request must pass through, in order. For each, enter one copy's availability, how many copies there are, and how many must be up for the tier to work: 1 for plain redundancy, 2 of 3 for a quorum or for capacity, all of them if each copy holds different data.

The result names the tier that contributes most of the downtime. That is where effort pays: improving any other tier barely moves the total until that one improves.

What this checks

  • The availability of a system built from tiers in series, where each tier has n identical components and needs k of them up, with every step of the formula shown.
  • Which tier contributes most of the expected downtime.

What it cannot know

  • Whether your failures are independent. Components sharing a zone, a deploy, a configuration or a dependency fail together, so real availability is lower than this.
  • Failover time, partial degradation or load. If a tier needs two of three copies to carry peak traffic, that has to be entered as Need up.
  • Measure anything. The percentages are the ones you enter.

Check it for real

avg_over_time(probe_success{job="<blackbox-job>"}[30d])

The fraction of synthetic checks that succeeded over 30 days, from the Prometheus blackbox exporter probing the service from outside. Compare it with the calculated figure: a large gap usually means failures are not independent. Prometheus blackbox exporter

Why the answer is a ceiling, not a forecast

The redundancy formula assumes copies fail independently. Copies in one zone, behind one switch, running one release or reading one bad configuration fail together, and a shared failure turns two copies back into one. That is why real outages so often take out every replica at once, and why the calculated figure is the best case.

It also assumes failover is instant and always succeeds. Time to detect a failure, and failovers that themselves fail, both add downtime the arithmetic leaves out.

Use the number to compare designs and to find the weakest tier, not to promise customers a figure. What you promise should come from what you measure.

Questions people ask about this

How do you calculate the availability of parts in series?

Multiply them. A request that needs every part succeeds only when all are up, so three parts at 99.9% give 0.999 × 0.999 × 0.999, about 99.7%. Every part in a chain lowers the total, so the total is always below the weakest part.

How much does a redundant copy add?

With n copies where any one is enough, the tier fails only when all n are down: 1 − (1 − a)n. Two copies at 99% give 99.99%. That figure holds only if the copies fail independently; copies that share a zone, a deploy or a configuration add far less.

Can I multiply my cloud providers' SLAs to get my availability?

The arithmetic works on any numbers, but an SLA is the level below which the provider owes service credits. It is a contract term, not a measurement, so the product tells you about credits rather than about what your users will see. Measure your own availability and use that.

Did this get you to an answer?

No text box on purpose — please do not paste production logs anywhere

Something wrong or out of date? Report it

Tools that go with this