Availability, the nines and SLAs/SLOs
In short: Availability is the share of time a service works as expected, often quoted in nines such as 99.9%. Each extra nine cuts allowed downtime tenfold. SLIs measure service health, SLOs set internal targets, SLAs are customer contracts, and the gap between perfection and the SLO is your error budget.
Measuring availability
Availability is the proportion of time, or of requests, for which a service works correctly. A simple formula uses two averages: MTBF (mean time between failures) and MTTR (mean time to repair or recover).
Availability = MTBF / (MTBF + MTTR)This shows two ways to improve: fail less often, or recover faster. In practice, cutting MTTR through good monitoring, automation and runbooks is often the cheaper path.
The nines
| Availability | Downtime per year | Downtime per 30-day month |
|---|---|---|
| 99% (two nines) | about 3.65 days | about 7.2 hours |
| 99.9% (three nines) | about 8.8 hours | about 43 minutes |
| 99.95% | about 4.4 hours | about 22 minutes |
| 99.99% (four nines) | about 53 minutes | about 4.3 minutes |
| 99.999% (five nines) | about 5.3 minutes | about 26 seconds |
Each extra nine costs much more: more redundancy, more automation and more careful change control. At five nines, a human cannot even log in and diagnose a fault within the monthly budget, so recovery must be automatic.
Calculating combined availability
When a request depends on several components in series (load balancer, web server, database), all must work, so you multiply their availabilities. Three components at 99.9% give roughly 99.7%. When components run in parallel and any one can serve, the service is down only if all fail at once: availability is 1 minus the product of each copy's chance of being down. Two independent servers at 99% each give 1 − 0.01 × 0.01 = 99.99%.
The catch is independence. Two servers on the same power feed, rack or software version can fail together, so real gains are smaller than the maths suggests.
SLIs, SLOs, SLAs and error budgets
- SLI (service level indicator): a measurement, such as the percentage of HTTP requests that succeed in under 300 ms.
- SLO (service level objective): the target for that SLI, such as 99.9% over 28 days. It is set by the team that runs the service.
- SLA (service level agreement): a contract with customers, usually with service credits if missed. It should be looser than the SLO so you get warning before breaching it.
The error budget is 100% minus the SLO. With a 99.9% SLO, 0.1% of requests may fail. If the budget is healthy, the team can ship changes faster; if it is spent, the focus shifts to reliability work. This turns arguments about "how reliable" into a shared, measurable rule.
Tip: measure SLIs from the user's point of view, such as successful requests at the load balancer, not just whether a server responds to ping.
Also check what an SLA excludes. Cloud provider SLAs often cover only deployments that use more than one availability zone, and usually exclude planned maintenance.
Practice
Roughly how much downtime per year does 99.9% allow?
A web tier at 99.95% depends on a database at 99.9%. What is the combined availability?
Why should an SLA be looser than the internal SLO?
Key takeaways
- Availability = MTBF / (MTBF + MTTR); faster recovery helps as much as fewer failures.
- Each extra nine cuts allowed downtime by ten times.
- Series dependencies multiply down; parallel redundancy raises availability.
- SLI measures, SLO targets, SLA promises customers.
- The error budget balances release speed against reliability.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.