SLO
9% of requests succeed within 300ms over a rolling 28 days' — used to define what 'reliable enough' means for a system and to drive data-driven decisions about when to prioritize reliability work versus new feature development.
Definition
An SLO (Service Level Objective) is a specific, measurable target for a service's reliability — such as '99.9% of requests succeed within 300ms over a rolling 28 days' — used to define what 'reliable enough' means for a system and to drive data-driven decisions about when to prioritize reliability work versus new feature development.
Overview
SLOs are the centerpiece of Site Reliability Engineering (SRE) practice, popularized by Google's SRE book, and sit within a small family of related terms that are often confused: an SLI (Service Level Indicator) is the actual measured metric (e.g. the percentage of requests that returned successfully, or the p99 latency), an SLO is the target threshold set for that indicator (e.g. 'SLI should be ≥ 99.9%'), and an SLA (Service Level Agreement) is an external, often contractual commitment to customers — typically set looser than the internal SLO, so that the SLO acts as an internal early-warning threshold that gets crossed before the customer-facing SLA is actually violated. The key innovation SLOs bring is the concept of an error budget: if an SLO target is 99.9% availability over 28 days, the remaining 0.1% is an explicit, quantified budget for acceptable failure — intentionally not 100%, because pursuing ever-higher reliability has steeply diminishing returns and directly trades off against development velocity (more caution, more testing, slower releases). As long as a service is operating within its error budget, teams are free to ship features, take some risk, and move fast; once the error budget is exhausted, the team commits to pausing feature work and prioritizing reliability improvements until the budget recovers. This turns 'how reliable should this service be' from a vague aspiration or political argument into a concrete, pre-agreed policy that removes ambiguity during incidents and roadmap planning. Setting good SLOs is itself a skill: overly strict SLOs (e.g. 99.999%) impose enormous engineering cost for reliability improvements users may not even notice or value, while overly loose SLOs fail to protect user experience. Good practice ties SLOs to what users actually care about (successful checkout completion, not raw server uptime), measures them from the user's perspective where possible (client-side or edge measurements rather than only server-side), and reviews them periodically as the service and its usage evolve. SLOs, backed by observability pipelines that generate the underlying SLIs, are now a standard operating model across most mature engineering organizations for balancing reliability investment against feature velocity.
Key Concepts
- A measurable, specific reliability target for a Service Level Indicator (SLI), e.g. 99.9% success rate
- Distinct from SLA (external, often contractual commitment) and SLI (the raw measured metric)
- Introduces the error budget: the quantified acceptable amount of unreliability within the SLO period
- Error budget exhaustion typically triggers a policy shift toward prioritizing reliability over new features
- Popularized by Google's Site Reliability Engineering (SRE) practice and book
- Should be tied to what users actually experience, not just infrastructure-level uptime
- Measured over a defined rolling time window (e.g. 28 or 30 days)
- Relies on observability pipelines/monitoring to continuously generate the underlying SLI data