A release is ready, but customers have repeatedly waited too long for account statements. Product wants the new feature shipped. The on-call team wants the document pipeline fixed first. Whether the servers are green right now does not settle the argument. The company needs to know what quality it intended to deliver, how far it has drifted and what another release might put at risk.
An SLO sets a measurable service-quality target over an agreed period. The error budget describes the tolerated share of unsuccessful outcomes relative to that target. These become useful when the evidence changes priorities, rather than simply adding a number to a report.
Agree on what a good statement means
Suppose customers should receive a correct statement within an agreed time. An SLI can measure the fraction of eligible operations that achieve that result. “Request accepted” is not enough: the document does not exist yet. Returning incorrect information quickly is not success either.
The denominator needs a definition. Which operations qualify? How are retries counted? What happens to jobs that never finish? Failed attempts should not be excluded merely because they never reached the final component. Otherwise an outage can improve the chart by making affected customers disappear from the calculation.
Server-side measurements, client observations and synthetic checks each have blind spots. Record those limitations beside the indicator. The Google SRE Workbook discusses measurement boundaries and user-oriented indicators. Choose the outcome first rather than inheriting whatever a monitoring dashboard happens to count.
Put actual arithmetic behind the budget
Consider an illustrative target, not a universal recommendation: 99.9% of eligible operations succeed over 28 days. If the completed period contains 100,000 operations, the tolerated 0.1% is 100 unsuccessful operations. Sixty failures consume 60% of that budget. More than 100 means the target was missed for that period.
This is a budget of operations, not downtime minutes. When traffic varies, equal outage durations can affect very different amounts of work. Time-based availability needs a different indicator; it cannot silently replace a request-based calculation.
Choose a calendar or rolling window explicitly. In a rolling window, old events leave the calculation and the total operation count changes. The first day of the month does not automatically reset it. During an ongoing period, the remaining budget is not a fixed pile of permitted failures to spend.
Do not wait for the allowance to run out
Suppose 1% of recent operations are failing when the target tolerates 0.1%. Their ratio is ten: a 10x burn rate. It expresses how quickly failures are consuming the allowance relative to the objective. It does not predict an exact exhaustion time without assumptions about future traffic.
A short observation window can expose a sharp incident; a longer one can detect sustained deterioration. Using both helps distinguish an ongoing problem from a burst that has already stopped. At low traffic, one failure moves the percentage sharply, so alert rules need testing against the actual workload. The SRE chapter on SLO alerting explores these trade-offs.
An overall result can also hide a persistently affected group. A small branch that never receives statements on time gains little from everybody else's good experience. Relevant journey and customer-group checks help, without inventing a separate objective for every individual user.
What changes in the release plan?
A written policy should name actions, owners and the conditions for returning to normal delivery. It might pause expansion of a risky change and prioritise its underlying failure while allowing necessary corrective releases. A blanket prohibition on change can prevent the very fix the service needs.
Agree who may authorise an exception and which evidence they need. Define recovery too: the deterioration has stopped and there is a credible basis for proceeding. Simply waiting until bad events age out of the window can make a chart recover while leaving the defect untouched.
Google's example error-budget policy connects reliability evidence with priorities rather than punishment. For our statement service, that must mean a real change to feature commitments. Asking the team to fix everything while keeping every existing deadline is not a useful policy.
Some failures are not covered by the allowance
A data leak or corrupted financial record needs its own response even while the overall success rate is high. A quality budget does not authorise every kind of damage. An internal SLO is also not interchangeable with a customer's SLA; their purposes and counting rules can differ.
A supplier outage can still spoil the customer's result. Its cause informs recovery and future investment, but should not automatically vanish from a user-facing indicator. Define boundaries and exclusions before the incident rather than redesigning them to make the report look better.
The first useful outcome is a release decision
Begin with one important operation and measurements that product and engineering both trust. Before release, they should be able to see target performance, recent changes, affected groups and the agreed action. If evidence is missing, acknowledge uncertainty instead of assuming there is enough budget.
After several cycles, review the agreement itself. Did it stop a harmful rollout early enough? Did the team get time to address the cause? Do the indicators agree with customer complaints? Those answers should drive the next revision, rather than a desire to add another nine to the objective.