SLA vs SLO vs SLI
Published
A pizza chain promises "delivered in 30 minutes or it's free". That is an SLA, a service level agreement: a promise to customers with a penalty attached. Inside the company, the manager tells the kitchen "95% of orders out the door in 18 minutes", because if the kitchen only just met 30 minutes, the chain would be giving away pizzas every night. That internal target is an SLO, a service level objective. And the clock on the wall timing each order from call to doorstep is the SLI, the service level indicator: the thing actually measured.
So: SLI is a measurement. SLO is your target for it. SLA is a contract built on a looser version of that target.
Your team's checkout API has a 99.9% availability SLO per 30 days. By day 10 you have already had 35 minutes of errors. A big feature is due to ship on day 11. Should it ship? What would you base the decision on?
SLI: what you measure#
A good SLI is a ratio of good events to valid events, measured as close to the user as you can:
- Availability: successful requests / all requests (excluding the client's own 4xx errors).
- Latency: requests faster than a threshold / all requests, for example "served in under 300 ms". A ratio of requests under a threshold is easier to reason about than an average.
- Freshness for pipelines: share of data updated within the last N minutes.
- Correctness for anything that computes: share of results that were right.
Measure what users feel. CPU at 90% is not an SLI; checkout requests failing is.
SLO: the target you choose#
An SLO is a target for an SLI over a window: "99.9% of checkout requests succeed, measured over a rolling 30 days." Choosing it is a product decision. Every extra nine costs roughly ten times the engineering and infrastructure (see availability and the nines), and users rarely notice the difference between 99.99% and 99.999% because their own phone network fails more often than that.
100% is the wrong target. It is impossible, and pretending otherwise means never shipping.
Error budget: the useful part#
Flip the SLO around and you get the error budget: how much failure you are allowed. A 99.9% monthly SLO means 0.1% of requests, or about 43 minutes of full downtime, may fail in 30 days. That budget is something you spend: on deploys that go wrong, on experiments, on risky migrations.
Most of the budget is gone with the month still running. Ship small, behind flags and canaries, or wait.
The error budget turns the old fight between "ship faster" and "keep it stable" into arithmetic both sides agreed to. Budget left: ship. Budget gone: fix reliability first. This is the core of Google's SRE practice.
Alerting on burn rate#
Alerting when the error rate crosses a fixed number is noisy. Alerting on burn rate, how fast you are spending the budget, ties pages to user impact. A burn rate of 1 uses the budget exactly over the window; 14.4 uses 2% of a 30 day budget in one hour. The Google SRE workbook suggests paging on fast burns (over short and long windows together, to avoid flapping) and opening a ticket for slow ones.
SLA: the contract#
An SLA is a legal promise to customers, with consequences, usually service credits: AWS, Google Cloud and Azure refund a percentage of the bill when a service misses its stated monthly uptime, with bigger refunds for bigger misses. Two rules:
- Your SLA must be looser than your SLO. If you aim for 99.9% internally, promise 99.5%. The gap is your safety margin, so that missing your own target does not cost money.
- You cannot promise more than your dependencies give you. A service on one cloud region whose SLA is 99.9% cannot honestly offer 99.99% without running in more than one region.
Not every service needs an SLA. Every important service needs an SLO.
| Choice | What you gain | What you pay | Pick it when |
|---|---|---|---|
| SLI | An honest measurement of what users experience. | Must be measured carefully: from the load balancer or client, excluding invalid requests. | For each user flow: checkout, search, login. |
| SLO | A shared target and an error budget that guides release decisions. | Needs agreement between product and engineering, and a policy that is actually followed. | Every service users depend on. |
| SLA | A commercial promise customers can rely on and sell against. | Money or credits when broken; legal and sales overhead. | Paid B2B products and platforms. Set looser than the SLO. |
- PrometheusSLIs as recording rules, burn rate alerts
- GrafanaSLO dashboards and error budget panels
- DatadogBuilt in SLO tracking
- Google CloudCloud Monitoring SLOs; Google wrote the SRE book
In the interview#
Checkpoint#
1. How much downtime does a 99.9% SLO allow per 30 days?
2. Why should an SLA be looser than the SLO?
3. The error budget is used up halfway through the month. Under a typical policy, what happens?
- SLI: measurement. SLO: internal target. SLA: contract with penalties.
- SLI = good events / valid events, measured near the user.
- 99.9% per 30 days = 43 minutes. 99.99% = 4.3 minutes.
- Error budget = 1 - SLO. Spend it on change; stop when it is gone.
- SLA looser than SLO. Alert on burn rate, not raw thresholds.
An SLI is a measurement of what users experience, best expressed as good events over valid events, like the share of checkout requests that succeed or finish under 300 milliseconds, measured at the load balancer. An SLO is the target we set for an SLI over a window, such as 99.9% over 30 days, chosen as a product decision because each extra nine costs far more; never 100%. One minus the SLO is the error budget, 43 minutes a month at 99.9%, which we spend on releases and experiments, and when it is exhausted, an agreed policy pauses risky launches in favour of reliability work. I alert on burn rate, how fast the budget is being spent, rather than raw thresholds. An SLA is the external contract, usually with service credits, and it must be looser than the SLO and no stronger than what our own dependencies promise.