| SLOs Nobody References | SLOs Teams Actually Use | |
|---|---|---|
| Target selection | Copied from a template, often 99.99% regardless of user need | Derived from actual user tolerance and current baseline performance |
| Ownership | Set once by a platform team, never revisited | Owned by the service team, reviewed every quarter |
| Consequence when missed | None, or a vague “we should look into this” | A written error budget policy that gates releases automatically |
| Visibility during incidents | Buried in a separate reporting tool | Surfaced directly in the incident channel and paging alert |
| Relationship to alerting | Static infrastructure thresholds, unrelated to the SLO | Burn-rate alerts derived directly from the SLO and error budget |
Why Most SLOs End Up Ignored
Almost every mature engineering organization has SLOs written down somewhere. Far fewer organizations have SLOs that anyone actually looks at during an incident, a planning meeting, or a release decision. The gap between “we have SLOs” and “we use SLOs” comes down to one thing: whether the SLO is connected to a real decision. Google’s SRE Workbook is explicit about this in its error budget policy guidance, an error budget policy is not a scoreboard, it is a rule that changes team behavior automatically when reliability drops below an agreed threshold, for example halting non-critical releases until the service recovers back inside its target.
Without that connective tissue, an SLO becomes decorative. Teams write a 99.9% availability target, wire it into a dashboard, and then continue shipping releases at the same pace whether the budget is full or exhausted, because nothing was ever written down that says otherwise. The number exists, but it drives no decisions, which means it was never really an SLO in the operational sense, just a reporting artifact.
This matters more as systems get more complex. Distributed architectures depend heavily on clear, referenceable reliability targets precisely because no single engineer can hold the entire system’s behavior in their head anymore; the SLO is supposed to be the shared, trusted number everyone defers to when a service is degraded but not fully down. If that number is not trusted, teams fall back to gut feel and Slack arguments during incidents, which is slower and less consistent than a working error budget policy would be.
There is also a rollout problem that has nothing to do with math. SLOs imposed top-down by a platform or SRE function, without the service team’s buy-in, tend to get quietly ignored the same way an unenforced coding standard does. The organizations that get real adoption usually start with one or two flagship services, let the owning team help set the target and write the policy, and let the results speak for themselves before rolling the practice out more broadly. A mandated SLO nobody helped design rarely survives its first uncomfortable release-gating decision.
The underlying idea traces back to Google’s internal SRE practice, where the error budget concept was originally developed to resolve a structural tension between development teams that wanted to ship quickly and operations teams that wanted to preserve stability. Framing reliability as a spendable budget, rather than an unconditional obligation, turned an adversarial argument into a shared, numeric negotiation: as long as the budget has room, ship fast; once it is gone, prioritize stability, and both sides agree on the rule in advance rather than relitigating it during every release conversation.
SLI, SLO, and Error Budget: The Mechanics That Matter
Pick SLIs That Reflect What Users Actually Experience
A service-level indicator should measure something a real user would notice, request latency at a percentile that reflects the typical experience, availability of a critical user journey, or correctness of a specific API response, not an internal proxy like CPU utilization or queue depth. Google’s SRE Workbook recommends anchoring latency SLIs on percentiles that capture both the typical experience and the long tail, since averages hide exactly the slow requests that frustrate users most. A p50 latency figure can look perfectly healthy while a meaningful share of real users sit in a slow, frustrating p95 or p99 tail, which is why mature SLIs are usually expressed as a percentage of requests meeting a latency threshold rather than as a single average number.
Set the SLO Target From Evidence, Not Convention
Availability targets across real production services commonly range from two nines to five nines, and the right number for a given service depends on genuine user tolerance and current baseline performance, not on copying whatever number a blog post used. A service where a few seconds of degraded response barely registers with users does not need a 99.99% target; a payment authorization path very likely does. Setting the target too aggressively for the actual user need just guarantees a permanently exhausted error budget and a policy nobody respects.
Turn the Budget Into a Written Policy, Not a Chart
The error budget is simply 100% minus the SLO target, expressed as an allowable amount of unreliability over a rolling window. What makes it useful is the policy that fires when the budget burns down: if a service has exceeded its error budget for the preceding window, feature releases other than urgent fixes are held until the service returns inside target. Google’s SRE Workbook frames this explicitly as permission, not punishment, a way of giving a team unambiguous authority to prioritize reliability work over new features when the data says reliability is what actually matters right now.
Figure 1: How an SLI, SLO, and error budget connect to a release decision
A service-level indicator such as request success rate feeds a rolling measurement against the service-level objective; the gap between actual performance and the target defines the remaining error budget, and a written policy converts budget status directly into a release gate rather than leaving the decision to informal judgment.
| SLO Target | Allowed Downtime per 30-Day Window | Typical Use Case |
|---|---|---|
| 99% (two nines) | About 7 hours 18 minutes | Internal tools, non-critical batch services |
| 99.9% (three nines) | About 43 minutes | Standard customer-facing web applications |
| 99.95% | About 21 minutes | Core transactional APIs |
| 99.99% (four nines) | About 4 minutes 22 seconds | Payment processing, safety-critical paths |
Writing SLOs People Actually Reference During Incidents
The test of a good SLO is simple: does someone pull it up mid-incident to decide how urgently to respond, or does it sit untouched until the quarterly review. SLOs that pass this test share a few traits. They are scoped to a single, specific user journey rather than an entire service, worded in plain language an on-call engineer can parse in five seconds, and tied directly to the paging system so a burn-rate breach actually pages someone instead of merely updating a chart. Google’s SRE Workbook guidance on alerting is direct about this connection, SLOs that measure reliability as customers experience it provide the highest-quality signal for when an on-call engineer should respond, and that signal should feed alerting rules rather than sit in a separate reporting layer disconnected from on-call rotations.
Multi-window, multi-burn-rate alerting is the specific technique that makes this practical: a fast-burn alert catches a severe, short-duration problem quickly, while a slow-burn alert catches a smaller but sustained degradation that would otherwise exhaust the budget quietly over days without ever looking urgent enough to page anyone in the moment.
| Burn Rate Window | What It Detects | Typical Response |
|---|---|---|
| Fast burn (short window, high rate) | Severe, acute degradation consuming budget quickly | Immediate page to primary on-call |
| Slow burn (long window, moderate rate) | Sustained, lower-severity degradation over days | Ticket or lower-urgency notification for investigation |
Figure 2: Multi-window burn-rate alerting compared to a single static threshold
A single static threshold either fires too often on brief blips or misses slow, sustained degradation entirely; pairing a short, high-rate window with a longer, moderate-rate window catches both failure shapes while keeping the total number of pages manageable for the on-call rotation.
Error-Budget-Driven Release Gating in Practice
The most concrete way an SLO earns its keep is by gating releases. A working policy states plainly: when the error budget for the trailing window is exhausted, only urgent fixes and security patches ship until the service is back within target; ordinary feature releases pause. This is not a bureaucratic hurdle, it is the mechanism that keeps a team from unknowingly shipping a fifth risky feature onto a service that has already used its entire reliability budget for the month. Making the gate automatic, wired into the deployment pipeline rather than dependent on someone remembering to check a dashboard, is what separates a policy that actually changes behavior from one that exists only in a wiki page.
In practice, teams that automate this gate usually tie it to the same feature-flag and canary infrastructure they already use for progressive rollout: a deployment pipeline checks current error budget status before promoting a canary to full traffic, and if the budget is exhausted, the pipeline holds the release at canary stage or blocks promotion entirely rather than relying on a human to remember to check first. This keeps the gate consistent regardless of who is running the release, and it means the policy applies the same way at 2 p.m. on a Tuesday as it does during a rushed Friday afternoon deploy.
This connects directly to postmortem culture: a service that keeps blowing through its error budget quarter after quarter is a pattern a good postmortem process will surface, and the fix is very often organizational, insufficient reliability investment, not a single bad deploy.
Composite services add a wrinkle worth planning for early: when a user-facing journey depends on three or four downstream services, each with its own SLO, the end-to-end experience can breach its target even while every individual dependency stays within its own budget, simply because failure probabilities compound across the chain. Teams that only watch per-service dashboards miss this entirely, which is why a top-level, journey-scoped SLO for the full request path is worth maintaining alongside the individual service SLOs that feed into it, not instead of them.
Common mistake
Setting an SLO target the team does not actually believe in, often because a customer contract or a leadership mandate specified a number without evidence behind it. When the target does not reflect real user tolerance or real baseline performance, the error budget is either always full, meaning the SLO says nothing useful, or always exhausted, meaning nobody respects the gating policy because it never lets anything ship.
Common mistake
Building an error budget policy and never wiring it to anything. A written policy that lives in a document nobody opens during a release decision has the same effect as having no policy at all; the gate has to be visible and, ideally, enforced automatically at the point where a release actually happens.
Common mistake
Using a single static alert threshold instead of multi-window burn-rate alerting. A static threshold either pages too often on short blips that never threaten the monthly budget, or stays silent during a slow, sustained degradation that quietly exhausts the entire budget before anyone notices.
What worked
Teams that rewrote their SLOs around a single specific user journey, rather than an entire service, saw error budget conversations become dramatically more useful in planning meetings, because “checkout success rate” is something a product manager can reason about in a way that “overall service availability” never was. Combining that scoped SLO with an automatic release gate tied directly to the CI/CD pipeline turned the error budget from a reporting artifact into the thing that actually decided whether Friday’s deploy shipped.
Bringing SLOs Into Planning, Not Just Incident Response
An SLO that only shows up during incidents is doing half its job. The more valuable use is proactive: reviewing error budget trends at the start of a planning cycle to decide whether the next sprint should prioritize new features or reliability work. A service that is comfortably within budget has earned the right to take on more release risk; a service that is close to exhausted has not, and that tradeoff should be visible to whoever is making roadmap calls, not buried in an SRE-only dashboard. This is also where SLOs intersect with observability cost control, since the SLIs feeding an SLO need reliable, well-instrumented telemetry, and teams that treat observability spend as infinite tend to over-instrument services whose SLOs never actually needed that level of granularity in the first place.
SLOs also need to extend into newer architectural areas as systems evolve. Services built around production model monitoring and LLM-backed features need their own SLIs, ones that reflect response quality and latency rather than only classic uptime, and teams that skip this step end up with an SLO framework that covers half their production surface while the newest, often riskiest, part of the system runs with no reliability target at all.
Getting organizational buy-in for this proactive use is often harder than the technical work of defining the SLI itself. Product managers and engineering leads need to see error budget status in the same planning artifacts they already use, a roadmap review, a sprint planning doc, rather than in a separate SRE tool they never open. Teams that succeed here usually pick one visible metric, remaining error budget percentage for the quarter, and put it directly on the same dashboard leadership already checks for delivery velocity, so reliability and feature work are weighed against each other using the same frame of reference instead of competing narratives from two different teams.
- Service-level indicator (SLI)
- A quantitative measure of a specific aspect of service behavior as experienced by users, such as request latency or success rate.
- Service-level objective (SLO)
- A target value or range for an SLI over a defined measurement window, expressing the reliability the team commits to delivering.
- Error budget
- The allowable amount of unreliability implied by an SLO, calculated as 100% minus the SLO target over the measurement window.
- Burn rate
- The speed at which a service is consuming its error budget relative to the rate that would exhaust it exactly at the end of the window.
- Multi-window, multi-burn-rate alerting
- An alerting technique combining a short, high-rate window with a longer, moderate-rate window to catch both acute and slow-burning degradation.
- Error budget policy
- A written, agreed rule specifying what changes, typically a release gate, when a service’s error budget is exhausted.
- Release gating
- The practice of pausing or restricting non-urgent deployments to a service once its error budget has been consumed.
- Service-level agreement (SLA)
- A formal, often contractual commitment to customers, usually set looser than the internal SLO to leave working margin.
Key Takeaways
- An SLO only earns its keep when it is connected to a written, enforced decision, most commonly a release gate tied to the error budget.
- Scope SLIs to specific, user-facing journeys rather than whole services so the resulting error budget conversation stays concrete and actionable.
- Set SLO targets from real user tolerance and baseline performance, not convention or an unexamined contractual number.
- Use multi-window, multi-burn-rate alerting so both acute and slow, sustained degradation get caught before the budget is silently exhausted.
- Wire the error budget policy directly into the release pipeline; a policy that lives only in a document changes nothing.
- Bring error budget trends into planning cycles, not only incident response, so reliability work competes fairly against new features.
- Extend SLO coverage to newer surfaces like LLM-backed features, which need their own quality- and latency-based SLIs rather than being left out of the framework entirely.
FAQs
What is the difference between an SLI, an SLO, and an SLA?
An SLI is the raw measurement, such as request success rate; an SLO is the internal target for that measurement; an SLA is a formal, often contractual, commitment to customers, typically set looser than the internal SLO so there is working margin before a customer-facing commitment is breached.
How do you calculate an error budget?
An error budget is simply 100% minus the SLO target, applied over the measurement window. A 99.9% availability SLO over 30 days implies roughly 43 minutes of allowable downtime, and that allowance is what teams track as the error budget.
Why do most SLOs never actually get used?
Most SLOs are set once, wired into a dashboard, and never connected to a real decision like a release gate or a paging alert. Without that connection, the number has no consequence attached to it, so teams stop referencing it during incidents or planning.
What is error-budget-driven release gating?
It is a written policy stating that once a service’s error budget is exhausted for the measurement window, only urgent fixes ship until the service recovers inside its target; ordinary feature releases pause. Making the gate automatic in the deployment pipeline is what makes it effective rather than symbolic.
What is multi-window, multi-burn-rate alerting?
It combines a short-duration, high-rate alert window that catches acute severe degradation with a longer, moderate-rate window that catches slow, sustained degradation. Using both avoids the common failure of a single static threshold that either pages too often or misses slow budget exhaustion.
Should every microservice have its own SLO?
Not necessarily every microservice, but every distinct user-facing journey should. Scoping SLOs around what a user actually experiences, like checkout or login, tends to produce far more actionable error budgets than scoping them around internal service boundaries that users never see directly.
How often should SLO targets be reviewed?
Quarterly review is a common and practical cadence, giving enough time to see real burn-rate trends without letting a stale, unrealistic target linger for a year. Targets should also be revisited after any major architecture change that shifts the service’s actual baseline performance.
How do SLOs relate to on-call and incident management?
SLO-derived burn-rate alerts give on-call engineers a trustworthy signal that reflects genuine user-facing risk, rather than arbitrary infrastructure thresholds, which reduces nuisance pages and makes escalation decisions clearer during an active incident.
References
- Google SRE Workbook, “Implementing SLOs”: https://sre.google/workbook/implementing-slos/
- Google SRE Workbook, “Error Budget Policy”: https://sre.google/workbook/error-budget-policy/
- Google SRE Workbook, “Alerting on SLOs”: https://sre.google/workbook/alerting-on-slos/
- Google SRE Book, “Service Level Objectives”: https://sre.google/sre-book/service-level-objectives/
- DORA, “State of DevOps Report”: https://dora.dev/research/2024/dora-report/
- Atlassian Incident Management Handbook: https://www.atlassian.com/incident-management/handbook
