Guides
An SLO Without a Decision Is Just a Percentage
A useful SLO changes release, staffing, or reliability work before the error budget is gone. Start with the decision, then choose the indicator and objective.
· Vight team · 7 min read
SLO guide
Turn reliability into policy.
It is easy to create an impressive SLO page: choose 99.9%, draw a green line, and show a countdown of remaining error budget. It is harder to say what the team will do when the budget burns faster than planned.
Without that answer, the objective is decorative. A useful service-level objective is a decision contract between product velocity and reliability work.
01
Start with the user journey
Define the event a user needs to succeed before choosing a metric. “Checkout completes with a valid result within two seconds” is closer to a service promise than “the checkout service is up.” It includes correctness and latency while leaving room to define exactly which requests count.
Choose the measurement point that best represents the experience. Server-side telemetry may be appropriate for an internal API; an edge, client, or synthetic measurement may better represent a public journey. Document exclusions such as invalid requests and deliberate rate limiting so the denominator cannot drift during an incident.
Event
Describe one attempt from the user or consumer's point of view.
Good
Define the status and latency that make that event successful.
Total
Specify the eligible population, including explicit exclusions.
02
Choose an objective that leaves room to operate
The target should reflect user expectations and business consequences, not the number with the most nines. Moving from 99.9% to 99.99% cuts the allowed bad events by a factor of ten and may demand a very different architecture and on-call posture.
Use historical performance as evidence, but do not simply relabel the current average as a promise. An objective should be achievable enough to guide tradeoffs and demanding enough that exhausting the budget triggers a real response.
03
Use burn rate to separate urgency from exhaustion
Budget remaining answers how much failure the objective period can still absorb. Burn rate answers how quickly the budget is disappearing now. You need both: a service may have plenty of monthly budget left while a severe regression is consuming it at a rate that will erase it within hours.
Compare a short window with a longer confirmation window. The short window detects urgency; the longer one rejects brief spikes. Page on a fast, sustained burn and route slower consumption into planned reliability work.
04
Write the policy next to the objective
Decide what happens at meaningful budget states. A healthy budget may allow normal release pace. Sustained burn may require an owner and mitigation plan. Exhaustion may pause risky changes until the service returns to an agreed trajectory.
The policy should also say who can make exceptions, how launches are evaluated, and when the objective itself is reviewed. Otherwise every difficult moment turns into a fresh negotiation, which is exactly what the SLO was meant to prevent.
05
Keep the objective connected to evidence
An SLO alert should open into the affected service, route, traces, logs, recent releases, and the exact windows used for the burn calculation. Responders need to move from policy breach to concrete failures without rebuilding the scope by hand.
Review the SLO when users report pain that it misses, or when it repeatedly burns without meaningful impact. The objective is a model of reliability, and production evidence should be allowed to improve the model.
Pick the decision first. Then define the indicator, objective, and burn policy that give the team enough evidence to make it consistently.