"The service must always be available" is a sentence you hear often and that helps nobody. It doesn't say what "available" means, doesn't indicate how to measure it and, above all, asks for something impossible. SLIs, SLOs and the error budget are a way to turn that sentence into concrete numbers, discussed between those who develop, those who run the infrastructure and those who set priorities.
Three acronyms, three levels
- SLI (Service Level Indicator): the measurement. For example, the percentage of requests that receive a correct response in under 300 milliseconds.
- SLO (Service Level Objective): the internal target for that measurement. For example, 99.5 percent of requests over a 30-day period.
- SLA (Service Level Agreement): the contractual commitment to a customer, with financial consequences if it is not met.
The SLA is usually less ambitious than the SLO. If you commit to 99 percent with customers, your internal target should be higher, so that you notice problems before breaching the contract.
Choosing good indicators
A good SLI reflects the user's experience, not the internal state of the machines. A server with CPU at 90 percent is not a problem if users get fast responses; a server with CPU at 10 percent is one if it returns errors.
The most common indicators are:
| Type of service | Typical SLI |
|---|---|
| API or website | Percentage of successful requests; percentage of requests under a certain latency |
| Background processing | Percentage of jobs completed within a certain time |
| Data storage | Percentage of reads returning the correct data |
| Data pipeline | Freshness: how recent the available data is |
It pays to express the SLI as a ratio of good events to total events. That makes it natural to think in percentages and compare different periods. Where you measure it matters: load balancer data is closer to the user's experience than that of a single server.
Why one hundred percent is the wrong target
Aiming for one hundred percent availability seems the most responsible choice, but it has three flaws.
- It is unreachable: networks, providers, updates and hardware failures ensure that sooner or later something stops.
- It is extremely expensive: each extra "nine" requires redundancy, automation and staff in growing proportion.
- It blocks change: if no error is tolerated, every release becomes an unacceptable risk and development slows down.
Moreover, beyond a certain level users cannot perceive the difference, because their own connection, device and home network are less reliable than the service.
To get your bearings, here is how much downtime some targets allow over a 30-day period:
| SLO | Allowed downtime in 30 days |
|---|---|
| 99% | About 7 hours 12 minutes |
| 99.5% | About 3 hours 36 minutes |
| 99.9% | About 43 minutes |
| 99.99% | About 4 minutes 19 seconds |
The error budget
If the target is 99.9 percent, the remaining 0.1 percent is the error budget: the amount of errors you can afford in the period. It is not a failure grudgingly tolerated, but a resource to spend.
The error budget is consumed by incidents, problematic releases and maintenance. Its value lies in the decisions it makes objective:
- if the budget is ample, new features can be released more often and you can experiment;
- if the budget is running out, releases slow down and you invest in stability;
- if the budget is exhausted, non-urgent changes are suspended until reliability is back on track.
This way the tension between those who want to add features and those who want stability is resolved with a shared criterion, rather than with arguments at every release.
SLO-based alerts
SLOs improve alerts too. Instead of waking someone up every time a server crosses a threshold, you raise an alert when the budget is being consumed too fast. An error rate that, if it continued, would exhaust the monthly budget in a few hours requires immediate action; slow consumption can wait until morning.
This logic, known as burn rate, reduces useless alerts and aligns urgency with the real impact on users.
How to start
- Pick an important service and one or two SLIs that represent what users care about.
- Measure for a few weeks before setting a target: the SLO must start from reality.
- Set an achievable SLO, slightly above the current level if that is unsatisfactory.
- Agree with the team what happens when the budget runs out, and put it in writing.
- Review the targets periodically: too easy and they guide nothing, too hard and they get ignored.
In short
- The SLI is the measurement, the SLO the internal target, the SLA the contractual commitment.
- A good indicator reflects the user's experience, not the internal state of the machines.
- One hundred percent is unreachable, expensive and holds back development.
- The error budget turns reliability into a resource and makes release decisions objective.
- Alerts based on budget consumption reduce noise and reflect real impact.
