SRE and Error Budgets
Site Reliability Engineering applies software engineering to operations and uses explicit reliability targets to manage tradeoffs. The central mechanism is the service-level objective: a measurable reliability promise for a defined user journey.
SLIs, SLOs, and Budgets
A service-level indicator is a measurement, such as the percentage of successful requests under 300 ms. A service-level objective is a target for that indicator, such as 99.9 percent over 30 days. The error budget is the allowed unreliability: if the SLO is 99.9 percent, the budget is 0.1 percent.
Error budgets turn reliability into an engineering control system. When the budget is healthy, teams can take more release risk. When it is burning too fast, the system is saying reliability work should outrank feature throughput.
Good Objectives
An SLO should represent user experience, not internal vanity. CPU usage is useful for diagnosis, but users care whether requests complete correctly and quickly.
Windows and Burn Rates
SLOs are evaluated over windows, such as 7, 28, or 30 days. The window changes behavior. A short window reacts quickly but may be noisy. A long window smooths noise but may hide sudden harm. Many teams alert on burn rate: how quickly the service is consuming its error budget compared with the allowed rate.
Fast burn alerts catch severe incidents. Slow burn alerts catch chronic degradation. Both matter. A service that is down for ten minutes needs immediate response. A service that is slightly too slow for two weeks may quietly exhaust the budget and harm users without a dramatic outage.
Policy Use
Error budgets are decision tools. When a team burns too much budget, it may pause risky releases, prioritize reliability work, reduce batch size, or improve observability. The policy should be agreed before conflict. Otherwise every budget discussion becomes a negotiation between feature pressure and reliability anxiety.
Example Objective
For an API, an SLI might be: the percentage of valid requests that return a non-5xx response within 300 ms at the load balancer. This definition excludes invalid client requests but includes server errors and latency. It is more user-centered than process uptime because a process can be alive while users receive timeouts.
Study Task
Write one SLO for a service. Include user journey, SLI formula, measurement source, objective, window, excluded events, alerting rule, and budget policy. If the SLI cannot be measured, the next task is instrumentation.
Operational Review
An SLO should be reviewed by product, engineering, and operations together. Product explains which user journeys matter most. Engineering explains what can be measured accurately. Operations explains which alerts and mitigations are realistic. Without this conversation, an SLO may become either a vanity target or an impossible promise.
The review should also test whether the objective changes decisions. If the team would deploy at the same pace, prioritize the same backlog, and alert the same way regardless of budget health, the SLO is decorative. A useful SLO has a policy: what happens when the budget is healthy, burning quickly, or exhausted.
Finally, compare the SLO with incident history. If recent incidents harmed users but did not affect the SLI, the indicator is too narrow. If the SLI pages constantly without user harm, the indicator or threshold is probably wrong.
Budget Arithmetic
SLO = 99.9
error_budget_percent = 100 -