SLI, SLO, and SLA Demystified
- SLI (Service Level Indicator): A carefully defined metric that measures service behavior (e.g., "percentage of HTTP requests returning in < 200ms with a 2xx status").
- SLO (Service Level Objective): An internal target reliability threshold agreed upon between product and engineering teams (e.g., "99.9% of requests meet the SLI over a 30-day rolling window").
- SLA (Service Level Agreement): A commercial contract with customers specifying legal and financial penalties (refunds, credits) if reliability drops below a contractual threshold (e.g., 99.5%).
The Error Budget Concept
A 100% target is usually impractical and can suppress useful change. If an availability SLO is 99.9%, its error budget is the remaining 0.1% of eligible events in the stated window. Teams use a written error-budget policy to decide which risky changes to slow or stop when burn is excessive; an automatic freeze of every release is one possible policy, not part of the definition, and urgent security or reliability fixes may still need to ship.
Worked example: what "three nines" actually allows
| SLO (30-day window) | Error budget | Allowed full downtime | At 50M requests/month |
|---|---|---|---|
| 99% | 1% | 7 h 12 min | 500,000 failed requests |
| 99.9% | 0.1% | 43 min 12 s | 50,000 failed requests |
| 99.95% | 0.05% | 21 min 36 s | 25,000 failed requests |
| 99.99% | 0.01% | 4 min 19 s | 5,000 failed requests |
Each extra nine cuts the budget by a factor of ten, and the engineering cost usually rises steeply with it. A 99.99% target leaves roughly four minutes a month, which is less than the time it takes a person to get paged, log in and roll back. At that level, detection and mitigation have to be automated.
Burn-rate alerting
Burn rate is how fast you are consuming the budget relative to an even spend. A burn rate of 1 uses exactly the whole budget over the 30-day window. The Google SRE Workbook recommends multi-window alerts such as:
| Burn rate | Long window | Short window | Budget consumed | Action |
|---|---|---|---|---|
| 14.4 | 1 hour | 5 minutes | 2% | Page |
| 6 | 6 hours | 30 minutes | 5% | Page |
| 1 | 3 days | 6 hours | 10% | Ticket |
Where 14.4 comes from: 2% of a 720-hour window is 14.4 hours of budget, and spending it in 1 hour is a 14.4x burn. For a 99.9% SLO, the page fires when the error ratio over the last hour is above 14.4 x 0.1% = 1.44%, and the last 5 minutes are also above that level. The short window makes the alert clear quickly once the problem is fixed.
Writing a good SLI
- Ratio form: good events divided by valid events. For example, requests to
/checkoutthat returned a non-5xx status within 300 ms, divided by all requests to/checkoutexcluding health checks. - Choose what users feel: availability and latency for APIs, freshness for data pipelines, durability for storage.
- Low-traffic services: at 100 requests per hour, a single failure is 1% of the hour. Use longer windows, synthetic probes, or combine several services into one SLO.
The error-budget policy
The written policy is what gives the budget any force. A typical policy says that while the budget is exhausted, only reliability fixes and security patches ship, and a postmortem is required for any single incident that used more than 20% of the budget. Product and engineering leadership agree to the policy in advance, so nobody argues about it in the middle of an incident.