SLI, SLO and SLA: Definitions, Examples and Error Budgets
An indicator measures how the service behaves, an objective says how good it should be, and an agreement says what you promise. Keeping them apart makes reliability a decision rather than a feeling.
Three abbreviations describe how reliability is measured and promised. They are related, and they are not interchangeable.
- SLI, service level indicator: a measurement of some aspect of service behaviour, such as the proportion of requests that succeed or the proportion served within a stated time.
- SLO, service level objective: a target for an SLI over a period, such as 99.9 percent of requests succeed over thirty days.
- SLA, service level agreement: a commitment to a customer, often in a contract and often with consequences if missed. An SLA is usually less strict than the internal SLO so that the team has margin.
Choose indicators that customers feel
Pick indicators from the user's point of view. For a service that answers requests, the common ones are availability, meaning the share of valid requests answered successfully, and latency, meaning the share answered within a threshold. Other services need freshness, correctness or throughput. Avoid internal measures such as CPU use as indicators. They can help diagnosis but they are not what a user experiences.
Measure at a point close to the user, such as the load balancer or the client, rather than deep inside, so that failures between the layers are counted.
Set the objective
Choose a target that reflects what users need, not the highest number you can imagine. Each additional nine costs much more than the last and may be invisible to users. Start from the current performance and from user expectations, set a target you can meet, and tighten it when you have evidence that users would benefit. State the period over which it is measured, commonly a rolling window of several weeks.
Calculate the error budget
The error budget is the amount of unreliability the objective allows. If the objective is 99.9 percent success over thirty days, the budget is 0.1 percent of requests. Over a thirty-day month of 43,200 minutes, 0.1 percent is about 43 minutes of full unavailability. The arithmetic is simple, and the consequence is useful: the budget turns reliability into a quantity that can be spent.
Use the budget to make decisions. While plenty remains, ship at the normal pace. When it is nearly spent, slow down releases and spend effort on reliability. This links the engineering and product views: both can see the same number.
Connect to releases and incidents
- Releases consume budget when they cause failures. Track whether releases are the main source of spent budget, and tighten the readiness checklist if so. See the release management guide.
- Incidents record how much budget was spent and why. Use the incident review to decide whether the SLO or the system should change.
- Freeze windows and rollback plans are controls that protect the budget. See the change freeze and rollback guides.
Common mistakes
- Too many SLOs. Two or three per service, tied to user journeys, are enough.
- Setting 100 percent. It is unattainable and leaves no budget for any change.
- Treating an SLO as an SLA. Missing an internal objective is a signal, and missing an agreement is a breach.
- Measuring from inside the system only.
- Never revisiting the objective after a real incident shows it was wrong.