Connect via MCP →

Enter Calculation

Formula

Advertisement

Results

Composite Availability
99.8001%
across 2 components
Downtime (%) 0.1999%
Downtime per year 17.51 hours
Downtime per month 87.56 min
Downtime per day 2.8786 min

What is a Composite SLA?

Modern systems are built from many moving parts — load balancers, databases, third-party APIs, CDNs and more. Each one carries its own Service Level Agreement (SLA) expressed as an uptime percentage like 99.9%. The composite (combined) SLA is the realistic availability of the whole system once those parts are wired together. This calculator combines individual component uptimes into a single end-to-end availability figure and translates it into concrete downtime per day, month and year.

Bar showing availability percentage mapped to yearly downtime
Higher availability percentages translate into dramatically less downtime per year.

Serial vs. parallel topology

The way components are connected dramatically changes the result. In a serial (dependency chain), every component must be available for the request to succeed, so availabilities multiply — the total is always lower than the weakest link:

$$A_{\text{total}} = \text{A}_1 \times \text{A}_2 \times \text{A}_3 \times \text{A}_4$$

In a parallel (redundant) setup, the system stays up as long as at least one path works, so you multiply the failure probabilities; redundancy pushes availability higher than any single component:

$$A_{\text{total}} = 1 - \left(1-\text{A}_1\right)\left(1-\text{A}_2\right)\left(1-\text{A}_3\right)\left(1-\text{A}_4\right)$$
Diagram comparing serial and parallel component topology with availability nodes
Serial (dependent) components multiply availability, while parallel (redundant) components combine to raise it.

How to use it

Pick your topology, then enter each component's uptime percentage (e.g. 99.95). Up to four components are supported; leave the optional fields blank to combine fewer. The result shows the composite availability plus the expected downtime across common periods.

Worked example

Suppose your app depends on three serial components each at 99.9%. Convert to fractions: $$0.999 \times 0.999 \times 0.999 = 0.997002999,$$ i.e. 99.7003%. That is a downtime of about 0.2997% — roughly 26.26 hours per year. Stacking "three nines" services in series only buys you "two nines" overall, which is exactly why redundancy matters.

FAQ

Why is my serial result lower than each input? Because every dependency adds a chance of failure; multiplying numbers below 1 always shrinks the total.

Does parallel really improve uptime that much? Yes — two independent 99% paths give \(1 - (0.01 \times 0.01) = 99.99\%\), assuming the failures are truly independent.

What does 99.9% mean in time? About 8.77 hours of downtime per year, or roughly 43.8 minutes per month.

Last updated: