SLO Definition Template

WHEN TO USE IT When a service has users who notice it being slow or broken, and the team needs a shared definition of "good enough" to make trade-offs with. Do not write SLOs for every service at once — start with the journeys whose failure a customer would actually report. HOW TO USE IT Define the journey before the metric. An SLO on a component nobody experiences directly measures your architecture, not your users. Work backwards: what does the user do, what makes that feel broken, and can you measure that from the outside? Agree the consequence before you need it. An error budget policy decided while the budget is being burned is a negotiation, not a policy. THE TEMPLATE # SLO: <user journey> Owner: <team> Reviewed: <date> Next review: <date> ## The journey What the user is trying to do, in their words. "A customer submits an order and sees confirmation." ## Indicator (SLI) The measurement, precisely. Include where it is measured from. Good events / valid events, defined so both terms are unambiguous: good = requests returning 2xx/3xx in under 400ms at the edge valid = all requests to POST /orders excluding health checks ## Objective <99.9>% over a <28>-day rolling window. Say why this number. "Because it is one nine better than last year" is a real reason; "because it looked right" is not. ## Error budget <0.1>% of valid events = roughly <N> failed requests per window. ## Error budget policy What changes when the budget is exhausted. Be concrete and agreed in advance: e.g. "feature releases pause; reliability work takes priority until the budget recovers; the decision to override belongs to <role>." ## What this SLO does NOT cover Named explicitly, so nobody assumes coverage that is not there. ## Dependencies Downstream services whose failures consume this budget, and whether their own objectives are compatible with this one. ADAPTING IT Internal platform services should express the journey in terms of their consumers' work, not their own API. Batch systems need a freshness or completeness indicator rather than availability and latency. The section teams most often skip is "what this does not cover", and it is the one that prevents an SLO from being quoted as a guarantee it never made. See /sre for the practice and /observability-engineering for the measurement.