How a composite SLA works
A composite SLA is the availability of a whole system built from several services. When every service has to work for the system to work, the services are in series and their availabilities multiply: 99.95% × 99.99% = 99.94%. The result is lower than the weakest part, because each dependency adds another way to fail. The Azure Well-Architected guidance on reliability metrics combines four adjusted targets, 99.98%, 99.95%, 99.80% and 99.99%, into a composite of 99.72%. The 4 in series example loads them.
Redundancy and replicas
When two copies can each carry the load, the system fails only when both fail at once. So you multiply the failure rates, not the availabilities: availability = 1 − (1 − A1) × (1 − A2). Two services at 99.9% give 1 − 0.001 × 0.001 = 99.9999%. The AWS Reliability Pillar puts it as 100% minus the product of the component failure rates.
In the calculator, set a service's role to Redundant and it joins the row above in one group. The group then counts as a single block in the series. The starting example is a 99.99% load balancer, two 99.95% app servers and a 99.99% database. The two app servers make a block of 99.999975%, and the whole system comes to 99.98%, or 8m 47s of downtime a month. The diagram under the result draws the same system: services in series from left to right, redundant copies stacked in a dashed frame, and the lowest block outlined.
A service can run several replicas and need more than one of them to carry the load. Open Add replicas on its row, then set how many replicas run and how many must be up. With 4 replicas at 99.9% where 3 must be up, the service is 99.9994%. Three replicas with no spare, all of which must be up, would be 99.7003%, and without the spare each instance would need about 99.9998% to match 99.9994%. For an autoscaled service, enter the replicas it runs and the number it needs at the load you care about, once for off-peak and once for peak. The calculator does not model how long a replacement takes to start or whether the autoscaler keeps up. It takes one availability figure per replica: if you have MTBF and MTTR, convert them first with MTBF ÷ (MTBF + MTTR). To find how many replicas a target takes, use the replica availability calculator.
Why it is an upper bound
The figure counts only the services you list. It leaves out your own code, deployments and configuration, which also cause downtime. Google Cloud's post on composite availability calls these figures upper bounds for that reason. A redundant group also assumes its copies fail independently, and copies that share a region, a network or a deployment pipeline often do not, so such a group is less available than the formula says. Use the result as a ceiling for planning, not as a promise to a customer.
Pitfall: the weakest block
The total can never be higher than the least available block. A third app server adds almost nothing if the database is the lowest block, so add redundancy where the lowest figure is. Provider SLAs apply only to a defined configuration and are republished over time, so this calculator has no presets: copy the figure from the current Azure, AWS or Google Cloud SLA that covers your setup. To see what a figure allows per day, week or quarter, use the uptime calculator.
FAQ
How do you calculate a composite SLA?
Multiply the availability of every service that has to work. A service at 99.95% and one at 99.99% in series give 0.9995 × 0.9999 = 0.99940005, or about 99.94%. The result is lower than the lowest service, unless every other service is at 100%, because every extra dependency is another way to fail.
How do you calculate the SLA of redundant services or replicas?
If any one copy can carry the whole load, multiply the failure rates and subtract from 1: availability = 1 − (1 − A1) × (1 − A2). Two services at 99.9% give 1 − 0.001 × 0.001 = 99.9999%. If several copies are needed to carry the load, add up the chances that enough of them are up. With 4 replicas at 99.9% where 3 must be up, that is 99.9994%, against 99.7003% for 3 replicas with no spare. Both assume the copies fail independently.
Is a composite SLA higher or lower than the SLAs it is made of?
It depends on how they are combined. Services in series give a figure no higher than the weakest of them. A redundant group gives a higher figure than its best member. A whole system is a series of such groups, so it can never be higher than its least available group.
Why is a composite SLA only an upper bound?
The figure only counts the services you list. It leaves out your own code, deployments, configuration and operations, which also cause downtime. For redundant groups it also assumes the copies fail independently. Copies that share a region, a network or a deployment pipeline can fail together, so a redundant group is less available than the formula says. Use the figure as a ceiling, not a promise.
Can I use the SLA numbers from my cloud provider, such as Azure, AWS or Google Cloud?
Yes, if you take the figure for the exact service and configuration you run. Provider SLAs apply only to a defined configuration, and providers publish new versions, so check the current SLA page. This calculator has no provider presets, so it never shows an outdated number. An SLA is a contract term, not a measurement of how often the service is up.
Does my own application count as a component?
Yes. Provider SLAs cover the provider's service, not your own code, so if the application has an availability target, add it as a component. Leaving it out makes the composite look better than the system you actually run.