Service Level Objective (SLO)

Definition

A Service Level Objective (SLO) is a specific, measurable reliability target for a service — such as '99.9% of requests succeed in under 300ms over 30 days' — used internally to guide engineering priorities and release decisions.

Overview

An SLO turns a vague goal like 'the service should be reliable' into a concrete number that can be tracked, alerted on, and used to make decisions. It's built from a Service Level Indicator (SLI) — the actual measured metric, such as request success rate or p99 latency — plus a target threshold and a measurement window. If the SLI is availability and the target is 99.9% over 30 days, that SLO permits roughly 43 minutes of downtime a month before it's breached. SLOs sit at the center of the site reliability engineering (SRE) model. The gap between the SLO and perfect reliability becomes the error budget — a quantified allowance that teams can 'spend' on risky deploys, experiments, or planned maintenance. Because the SLO is internal and self-imposed, teams can set it deliberately looser than 100% to leave room for the calculated risk that comes with shipping software quickly. SLOs are distinct from a Service Level Agreement (SLA), which is an external, often contractual promise to customers, typically with financial penalties attached. Good practice is to set the internal SLO stricter than the external SLA, so a team notices and reacts to degrading reliability well before it ever breaches a customer-facing commitment. SLOs depend on solid observability infrastructure — without accurate metrics pipelines, an SLO is just an aspiration with no way to verify whether it's being met.

Key Concepts

• Built from a measurable SLI (availability, latency, error rate, throughput) plus a target and time window
• Internal-facing, and typically set stricter than any external SLA to provide an early warning buffer
• Directly generates an error budget that governs release pace
• Tracked continuously via dashboards and alerting rather than checked manually
• Scoped per critical user journey rather than as one blanket number for an entire system
• Reviewed and adjusted periodically as usage patterns and business priorities change

Use Cases

Frequently Asked Questions

Related in DevOps