An SLO is a reliability decision expressed as a target for an important user-facing outcome. It is not a dashboard decoration and it is not the same as an infrastructure metric. A useful SLO says what users need, how the service will measure it, what level is acceptable, and what the team will do when the budget for failure is being spent. Google SRE's service-level objectives chapter distinguishes the indicator, objective, and external agreement; implementing SLOs helps translate that distinction into an operating plan. Start the SLO before the first build so architecture and telemetry serve a decision rather than a pile of charts.
Start with the user journey
Identify the journey whose failure matters: a page load, a checkout, a message delivery, a report run, an API request, or a recovery action. Describe the event that counts as good and the event that counts as unavailable, incorrect, or too slow. A service can be healthy at the host level while the user cannot complete the journey because a dependency, queue, or permission check fails. Google's SRE Workbook recommends beginning with user-facing service behavior. That framing helps teams choose an indicator that represents the product outcome and makes the target understandable to people outside the operations group.
| SLO component | Example | Decision it enables |
|---|---|---|
| User journey | A customer completes checkout | Which outcome deserves reliability investment? |
| SLI | Successful checkouts divided by eligible attempts | What events count as good service? |
| Objective | A defined percentage over a stated window | How much failure is acceptable? |
| Error budget | The complement of the objective | How much change risk remains? |
| Policy | Pause risky releases when budget is exhausted | What response follows the measurement? |
Choose an indicator that can be trusted
An SLI needs a clear numerator, denominator, eligibility rule, aggregation, and time window. Define how retries, synthetic checks, partial responses, cached results, and client cancellations are treated. Avoid an indicator that can be improved by hiding bad events or excluding the users who experience them. Test the calculation against real examples and known incidents. If the data source is incomplete, document the limitation and do not express false precision. A transparent imperfect indicator can improve; an opaque number will create arguments about the dashboard instead of decisions about the service.
- Name the user event and the population of eligible events.
- Define success, failure, latency, and partial completion explicitly.
- Record how retries, cancellations, timeouts, and synthetic traffic are handled.
- Check the indicator against incidents and representative user journeys.
- Version the definition when the product behavior or measurement source changes.
Set the objective and window
An objective should reflect the service's importance and the user's tolerance, not a fashionable number. Choose a time window that matches the decision: a rolling window can guide release policy, while a shorter window can support incident response. Make the objective specific enough that a team can tell whether it is meeting it, but avoid targets that the measurement cannot support. OpenSLO provides portable concepts for describing service levels, while the SRE material emphasizes that SLOs are a way to balance reliability and change. The target is a policy input, not a promise that the system will never fail.
Turn the budget into policy
The error budget is useful because it turns reliability into a resource that can be spent on change. State what happens when the budget is healthy, being consumed quickly, or exhausted. The policy might change rollout size, require extra review, prioritize reliability work, or pause nonessential releases. It should name an owner and a return-to-normal condition. Do not use the budget as a punishment for teams that inherit a poorly defined SLO. Review whether the indicator reflects the actual harm and whether the response is proportionate to the service's consequence.
| Budget state | Operational meaning | Possible response |
|---|---|---|
| Healthy | Reliability is within the agreed tolerance | Continue planned change with normal controls. |
| Consuming quickly | Recent failures may threaten the target | Investigate, reduce exposure, and review risky changes. |
| Near exhaustion | Little room remains for additional failure | Use staged releases and prioritize corrective work. |
| Exhausted | The reliability objective was missed | Pause selected changes until the recovery condition is met. |
| Untrusted measurement | The signal cannot support a decision | Repair the SLI before using its budget for governance. |
Alert on burn, not noise
Alerts should tell a team that a reliability decision needs attention. Alerting on SLOs describes burn-rate thinking: a fast enough rate of budget consumption deserves attention even if the long window still looks healthy, while a slow small deviation may not wake someone. Pair a short window with a longer window, route the alert to an owner, and include the affected journey and current budget state. Avoid turning every threshold crossing into an urgent page. An alert that cannot lead to a clear action will be ignored, and ignored alerts degrade the credibility of the SLO itself.
Connect SLOs to change and recovery
A release process should be able to see the relevant budget state before increasing exposure. An incident process should link symptoms to the user journey and preserve the SLO evidence used in the review. Recovery work should test whether the service can restore the outcome, not merely restart a process. Include dependency and regional effects when they change the user's experience. When an SLO is missed, ask whether the cause was a code change, capacity, dependency, measurement defect, or an unclear contract. The resulting action might be a rollout change, an architecture change, a better indicator, or a renegotiated objective.
Review the SLO as a living contract
Review SLOs on a regular cadence and after meaningful incidents or product changes. Compare the target with observed user tolerance, support tickets, business impact, and the cost of meeting the objective. A target that is too loose may permit damaging behavior; one that is too strict may create toil and block valuable work without improving the user journey. Keep the definition, owner, data source, policy, and effective date together. Retire SLOs that no longer describe a real service and create a replacement before removing their operational signal.
Avoid gaming the objective
Teams can improve an SLO without improving the user experience if the indicator excludes difficult cases, treats a partial response as success, or moves failure into a dependency the user still experiences. Review the SLI with support, product, and incident data. Compare it to user reports and business outcomes, and test whether a service could technically meet the target while customers remain blocked. A trustworthy objective makes undesirable optimization visible. When the indicator and the experience disagree, investigate the contract before changing the target.
Multiple indicators can describe one journey when a single number hides important failure modes. A checkout may need a completion SLI, a latency SLI, and a correctness or duplicate-charge measure. Keep the set small enough to operate and define which indicator governs which decision. Do not average unlike outcomes into a composite score that nobody can interpret. Separate availability, latency, freshness, and correctness when they have different owners or recovery actions. The purpose of the set is to reveal trade-offs, not create a more impressive dashboard.
Dependencies should appear in the service's reliability conversation without turning the SLO into a blame exercise. If a user journey depends on identity, payment, storage, or a third-party API, define how its failure appears in the user-facing SLI and which team owns the response. A local service may meet its internal target while the journey fails because a dependency is unavailable. Trace the failure path, establish escalation expectations, and avoid promising a target that the architecture cannot influence or explain.
SLO reviews are a good place to connect reliability with product change. A new feature may add a critical journey, alter the denominator, increase traffic variance, or introduce a data correctness requirement. Update the indicator and budget policy before the feature becomes the new normal. When an incident reveals a missing signal, add it to the SLO discussion instead of adding a one-off alert that has no owner. This keeps reliability evidence coherent as the product evolves.
A small SLO review group can keep the contract healthy. Include the service owner, an operations representative, a product or support voice, and someone who understands the measurement. Review budget consumption, incidents, user feedback, target suitability, alert quality, and pending architecture changes. Record decisions and effective dates. The group should be able to retire an SLO that no longer represents a meaningful journey and should have the authority to change policy when evidence shows the existing response is ineffective.
SLOs should also inform capacity and architecture choices. If the service repeatedly spends its budget during predictable demand peaks, the response may be capacity planning rather than a tighter alert. If latency is acceptable for most users but poor for a particular region or operation, segment the journey and investigate the cause instead of hiding the tail in an average. Use the SLO record to connect a reliability investment with the failure mode it is intended to reduce. This makes engineering trade-offs easier to explain to product and finance stakeholders.
Be careful when aggregating across services. A portfolio view can help leadership see reliability exposure, but averaging service objectives can hide a critical path that is failing. Keep the user journey and consequence visible in roll-up views, and retain the underlying SLI definitions. A service may meet its local target while the end-to-end journey misses its objective because failures compound. The roll-up should direct attention to dependency and ownership questions, not create a single score that replaces service-level understanding.
Finally, make the SLO understandable to the people who respond when it is missed. A runbook should state the affected journey, the current burn, the likely first checks, the owner, and the conditions for escalation. Product and support teams should know what a budget policy means for release timing or customer communication. When the target is visible in the workflow, it becomes a shared operating contract rather than a private reliability statistic.
An SLO review should also examine whether the alert is actionable at the time it fires. If the owner cannot tell which journey is affected or which change to pause, improve the alert context and runbook before adding another threshold. If the same burn repeatedly triggers without a useful response, change the policy or the underlying service. Reliability practice matures when the target, alert, response, and learning loop stay connected instead of becoming four separate dashboards owned by different teams.
Frequently asked questions
Question: Is a centralized log store automatically useful? Answer: No; event identity, structured fields, access controls, retention purpose, and query action matter more than collection volume. Question: What should a growing team standardize first? Answer: A durable event contract with time, source, outcome, correlation, sensitivity, and ownership fields.
How should an SLO start?
Answer: Start with a user journey, a trustworthy indicator, a target, an evaluation window, and an owner who can connect the budget to change and recovery.
What should an SLO alert do?
Answer: It should signal actionable budget burn or imminent user impact, with enough context for the responder to protect the service.
How can teams avoid gaming an SLO?
Answer: Keep the indicator close to the user outcome, inspect exclusions and segments, review near misses, and change the contract when the measurement no longer represents service quality.
What is the difference between an SLI and an SLO? The SLI is the measurement; the SLO is the target applied to it. Is an SLO the same as an SLA? No. An SLA is an external agreement that may include consequences, while an SLO is usually an internal reliability objective. Use observability engineering notes and SLOs in production to connect the target to instrumentation and lifecycle change. Does every service need the same objective? No; the target should reflect user impact, architecture, and business importance. Should an SLO measure infrastructure uptime? Only if that reflects the user journey; otherwise choose a more direct outcome. What if the measurement is wrong? Stop using it for budget policy, repair the definition, and document the gap rather than pretending the number is reliable.
Key takeaways
- Start with a user journey and define what good service means for that journey.
- Make the SLI calculation, eligibility, window, and limitations explicit.
- Set an objective that reflects consequence and can be measured honestly.
- Connect error-budget consumption to release, incident, and recovery policy.
- Review the SLO when product behavior, user tolerance, or measurement quality changes.
Conclusion
SLOs are decisions before they are numbers. A well-designed SLO gives a team a shared language for reliability, a measurement it can explain, a budget for change, and a response when the budget is spent. Start with the user, instrument the real outcome, and let the policy make the trade-off visible.