SLI, SLO, SLA
SLI (Service Level Indicator) is a quantitative measure of service behaviour (e.g. request latency, error rate). SLO (Service Level Objective) is the target value for that metric (e.g. 99.9% of requests under 200ms). SLA (Service Level Agreement) is a contractual commitment with financial or legal consequences for missing the SLO.
The three terms come from Google’s Site Reliability Engineering literature. The SLI measures reality, the SLO sets a goal, and the SLA turns a commitment into a contract.
How it works
An SLI is best expressed as a ratio of good events to total events, for example successful HTTP requests divided by all requests, or requests served in under a chosen latency threshold divided by all requests. That gives a value between 0% and 100%, and a consistent form that alerting and reporting tools can reuse.
An SLO is a target for that ratio over a time window, such as 99.9% of requests succeeding over 30 days. Google’s guidance is that 100% is the wrong target, because it blocks every change that could improve the service and depends on components you do not control.
The error budget is 100% minus the SLO. A 99.9% SLO over 30 days allows 0.1% of that time to be bad, which is 43.2 minutes if measured as pure downtime. For request-based SLIs the budget is a count of failed requests instead.
A practical example
A checkout API defines its SLI as the proportion of POST requests that return a non-5xx response. The SLO is 99.9% over a rolling 30 days. If the service handles 10 million requests in that window, the budget is 10,000 failed requests. Burn-rate alerts in Prometheus warn the team when the budget is being consumed too quickly, before it is gone.
Common mistakes
- Measuring what is easy, such as CPU usage, instead of what users experience.
- Setting SLOs by aspiration rather than from measured history.
- Setting the SLA equal to the SLO, which leaves no margin. Teams commonly set the internal SLO tighter than the contractual SLA.
- Having no agreed error budget policy, so an exhausted budget changes nothing.
- Defining dozens of SLOs. A few per user journey are easier to defend.
When to use it and when not to
Use SLIs and SLOs for any service where reliability trades off against delivery speed, and use an SLA only where a customer contract requires financial or legal consequences. For internal tools with few users, a simple availability target may be enough. Our SRE and incident response service covers SLI and SLO definition in more detail.
See also
Related service
View our SLI, SLO, SLA servicesLast updated: 2026-10-11