UptimePad

SLA, SLO and SLI: what each one means

The three terms are often used as if they meant the same thing. An SLI is what you measure, an SLO is the target you set for it, and an SLA is the promise to customers, with consequences if you miss it.

By Rai Ansar. Updated .

SLI: the measurement

A service level indicator is a carefully defined number that measures one aspect of the service. The Google SRE book gives request latency, error rate, throughput and availability as common examples. A useful SLI is usually a ratio of good events to all events, for example successful requests divided by total requests over five minutes.

SLO: the target

A service level objective is the target value or range for an SLI, for example 99.9% of requests succeed over a rolling 30 days. It is an internal goal. Missing it should change what the team works on, but it does not by itself cost anyone money.

SLA: the contract

A service level agreement is a contract with users that says what happens when the objectives in it are met or missed. The consequence is often financial, such as a service credit or a refund. The SRE book suggests a simple test: if nothing happens when the target is missed, it is an SLO, not an SLA. SLAs are normally looser than the internal SLO, so the team gets warned before the contract is at risk.

Error budgets

The error budget is what the SLO leaves over: one minus the objective. A 99.9% SLO over a rolling 30 days leaves 0.1% of that window, which is 43m 12s of full downtime, or the equivalent share of failed requests. While budget remains, the team can ship changes and take risks. When it runs out, the SRE book's answer is to pause releases and spend the time on testing and reliability work.

Note that 30 days is not the same window as a twelfth of a year. The same 99.9% gives 43m 48s over 30.42 days, which is the figure the uptime calculator shows for a month. The SLO calculator works out the budget for any target and window, and the burn rate part-way through it.

How they fit together

Pick the SLI first, because a target on the wrong measurement is worse than no target. Set the SLO from what users actually notice, then set any SLA below it with a margin. Track the error budget against the SLO, not the SLA.

Sources

Related