SLI, SLO and SLA in one example
An SLI (service level indicator) is a measurement of how a service behaves, such as the share of requests that succeed. A service level objective (SLO) is the target you set for that measurement over a period. The SLA (service level agreement) is a contract that promises customers a level of service and states what happens if you miss it.
For a checkout API, the three might look like this. The SLA target is looser than the SLO, which leaves a margin before a miss costs money.
- SLI: the proportion of valid requests that return a non-5xx response within 500 ms, measured at the load balancer.
- SLO: 99.9% of requests meet the SLI over a rolling 30-day window.
- SLA: at least 99.5% monthly availability, with service credits if the provider falls short.
How to choose a good SLI
A good SLI measures what users experience, and it's easiest to work with as a ratio: good events divided by valid events. That gives a percentage you can compare directly with a target.
Where you measure matters. Server logs miss requests that never reached the server, and load balancer data is closer to users. Synthetic checks and browser data are closest but noisier. Keep to a few SLIs per user journey, chosen from kinds like these:
- Availability: the share of requests that succeed. Decide which responses count as failures, since a 404 for a mistyped URL usually reflects the request, not the service.
- Latency: the share of requests faster than a threshold, such as 300 ms. A threshold works better than an average, which hides a slow tail.
- Freshness: for data pipelines, the share of records updated within a set time.
- Correctness: the share of results that are right, checked by sampling or with known test inputs.
Error budget arithmetic
The error budget is the amount of failure the SLO allows, the gap between the target and perfect reliability. A 99.9% SLO leaves 0.1%. Over 30 days, which is 43,200 minutes, that is 43.2 minutes of full downtime. For a request-based SLO it's 0.1% of requests, such as 1,000 failures out of 1,000,000.
Each extra nine cuts the budget by a factor of ten. Over a 30-day window:
- 99% allows 7.2 hours (432 minutes).
- 99.5% allows 3.6 hours (216 minutes).
- 99.9% allows 43.2 minutes.
- 99.95% allows 21.6 minutes.
- 99.99% allows about 4.3 minutes.
Spending the error budget
The budget turns reliability into a decision rule agreed in advance. While budget remains, the team ships changes and takes reasonable risks. When an incident or a bad release uses it up, a common policy pauses risky launches and puts that time into reliability work until the budget recovers.
Burn rate measures how fast you're using the budget. A burn rate of 1 uses exactly the whole budget over the window. At a burn rate of 14.4, one hour uses 2% of a 30-day budget, and Google's SRE Workbook uses that rate as a paging threshold.
Aiming for perfect reliability leaves no budget for change, and each extra nine costs more to meet. Set the SLO at the reliability your users need.
What an SLA adds
An SLA turns a reliability target into a contract with consequences. It defines the service covered, how and where availability is measured, and the reporting period. It also lists exclusions such as scheduled maintenance and explains how customers claim compensation, usually as service credits.
Because missing an SLA costs money, its targets are usually looser than the internal SLO. Many internal services have SLOs and no SLA at all. An SLA is only as good as the measurement behind it, so both sides should agree on the data source.