Reliability arguments without numbers go nowhere. Someone says the service is unreliable, someone else says it is fine, and the discussion resolves according to who is more insistent. A service level objective replaces that with arithmetic: here is what we promised, here is what we delivered, here is how much room remains.
The error budget is what makes it more than reporting.
What changed in 2026
- Burn rate alerting displaced threshold alerting. Alerting on how fast the budget is depleting, rather than on raw error counts, reduced noise substantially.
- Client-side measurement spread. Recognition that server-side success rates miss failures users experience pushed measurement toward the client.
- Budget policies got written down. Documenting what happens when a budget depletes, before it does, became standard rather than an improvised conversation.
- Over-targeting got called out. Teams setting reliability targets far beyond what users needed, at large cost, became a recognized anti-pattern.
Defining a useful objective
| Component |
Requirement |
| Indicator |
Something a user experiences, measured directly |
| Target |
A percentage over a defined window |
| Window |
Rolling, typically weeks rather than a calendar month |
| Measurement point |
As close to the user as practical |
| Scope |
One user journey, not the whole system |
The indicator choice determines whether the objective means anything. Server-side request success rate is easy to measure and misses everything between your server and the user — network failures, client errors, timeouts on the user's side. Measuring at the client captures what people actually experience, which is the point.
Scope matters too. An objective covering the entire service averages a critical checkout flow with a rarely-used settings page, and the average hides the failure that matters. Separate objectives per important journey are more work and more useful.
Using the budget
If your target is a given percentage over a window, the difference between that and one hundred percent is your error budget — the amount of failure you have decided is acceptable.
While budget remains, the team ships. Spending budget is not failure; it is using an allowance that exists precisely so that shipping is possible.
When budget depletes, something changes. That is the mechanism, and the policy must be written before it happens: freeze feature releases and work on reliability, require additional review for changes, or escalate for an explicit decision to continue. A depleted budget with no consequence is a number on a dashboard.
Alert on burn rate rather than on absolute errors. A burst of errors consuming a small fraction of a monthly budget is not an emergency; a rate that will exhaust the budget in hours is. Multi-window burn rate alerting — a fast burn triggering immediately, a slow burn triggering after sustained depletion — gives urgency proportional to consequence and produces far fewer pages than threshold alerting.
Resist over-targeting. Each additional nine of availability costs disproportionately more, and users generally cannot perceive the difference above a certain point, particularly when their own network is less reliable than your service. Setting a target higher than the user experience warrants spends engineering capacity on something nobody notices.
The operational side of responding when budget burns is in runbook writing guide, and the learning side in incident postmortem guide.
Common mistakes
- Server-side-only measurement. Misses what users experience.
- One objective for the whole service. Averages away the failures that matter.
- No policy for depletion. The budget becomes reporting.
- Targets set by aspiration. Should reflect what users need, not what sounds impressive.
- Threshold alerting on errors. Noisy; burn rate is proportionate.
- Calendar-month windows. Produce a reset cliff and end-of-month risk aversion.
FAQ
What target should I pick?
Whatever your users actually need, informed by how reliable their own connection is. Higher is not automatically better given the cost.
Who owns the objective?
The team operating the service, with agreement from whoever depends on it. An objective imposed without the operating team's input does not change behaviour.
What if we blow the budget constantly?
Either the target is too aggressive or the service needs investment. Both are useful conclusions and the objective surfaced them.
Should every service have one?
Every user-facing journey that matters. Internal services can inherit from what they support.
Where to go next
For operational response, read runbook writing guide. For learning from failures, incident postmortem guide, and for the telemetry underneath, OpenTelemetry setup guide.