Service level objective (SLO)

An SLO has three parts: a service level indicator (SLI), a target and a compliance window. The SRE Workbook recommends expressing every SLI as a ratio of good events to valid events, so it ranges from 0 to 100% and has a uniform meaning: for availability, successful responses divided by all valid requests, excluding for example 4xx responses caused by clients; for latency, the share of requests served faster than a threshold such as 300 ms; and for pipelines, freshness, correctness or coverage. Latency SLOs are usually stated as a percentile target (99% of requests under 300 ms) rather than an average, which hides the tail. Time-based SLIs, which count good minutes instead of good requests, weight a quiet night the same as peak hour and so tend to misrepresent user impact.

The error budget is 1 minus the target applied to the window. At 99.9% over 30 days a service may fail 0.1% of valid requests, which is 1,000 failures per million requests or, for a time-based SLI, 43.2 minutes. Rolling windows (the last 28 or 30 days) reflect what users recently experienced and avoid the budget suddenly resetting on the first of the month; calendar windows align with business reporting and SLAs. Alerting should be driven by the burn rate, the speed at which the budget is being consumed, rather than by the instantaneous SLI.

The budget becomes a management tool through an error budget policy agreed in advance between product, development and operations: for example, when the budget is exhausted, feature releases pause except for reliability fixes and security patches until the service is back within target, and any single incident consuming more than a set share of the budget requires a postmortem. Without such a policy an SLO is just a dashboard. The corollary is that a large remaining budget is permission to take risk, such as faster rollouts or chaos experiments.

Targets should be set from user expectations and historical performance, not aspiration. 100% is the wrong target because users cannot distinguish it from very high availability behind their own imperfect networks, and pursuing it freezes change. An SLO also cannot realistically exceed the combined availability of hard dependencies, including third-party SLAs, without redundancy. Too many SLOs dilute attention; a few per critical user journey is typical. SLOs are best measured as close to the user as practical, at the load balancer or with client-side telemetry, because server-side metrics miss requests that never arrive. Specifications such as OpenSLO allow SLOs to be declared as code alongside services, and the SLO is then set stricter than any external SLA so that internal reaction precedes contractual breach.