SLO (service level objective)
Also called service level objective, SLI.
An internal reliability target for a service, such as 99.9% of requests succeeding, measured by a service level indicator (SLI).
Last updated
What it is.
Google's SRE book defines an SLI as a carefully defined measure of some aspect of service, such as request latency or error rate, and an SLO as a target value or range for that SLI. For example: 99.5% of search requests return in under 300 milliseconds, measured over 28 days.
The gap between 100% and the SLO is the error budget. While budget remains, the team can ship quickly. When it runs out, reliability work comes first. An SLA is usually set looser than the SLO.
Why it matters
Without SLOs, reliability is argued about by feel. With them, the team knows when things are good enough, when to stop shipping and fix, and what to alert on. They also make uptime promises to customers grounded in real data.
In a product build
Picking two or three SLOs for the user-facing paths, such as login and checkout, and wiring up monitoring for them belongs in the launch checklist of a product build.
Common mistakes.
- 01
Aiming for 100%. It is impossible and blocks every release.
- 02
Measuring server health instead of what users actually experience.
- 03
Too many SLOs, so none of them drive decisions.
Read the official text.
Primary sources this definition is based on.
- Google SRE book, Service Level Objectiveschecked 2026-10-25
Related terms.
- SLA (service level agreement)A contract that promises a level of service, such as uptime or support response time, and says what happens if it is missed.
- UptimeThe share of time a service is working and reachable, usually written as a percentage such as 99.9%.
- RTO (recovery time objective)How long a system can stay down after a failure before the outage seriously harms the business.
- RPO (recovery point objective)The point in time to which data must be recoverable after an outage: in practice, how much recent data you can afford to lose.
