slo-designlisted

# SLO Design Define what "working" means for a service, in terms a user would recognise, and alert only on that. ## Purpose **Use this when:** - Defining reliability targets for a service. - Alert fatigue is a problem, or an incident was missed by the alerts that existed. - Choosing between competing reliability work and feature work. - A new service is being onboarded to production. **Do not use this when:** - You are debugging a live problem — use `incident-triage` or `observability-debugging`. - The metrics needed do not exist yet — get instrumentation working first with `prometheus-troubleshooting`. **What this skill assumes:** request-level metrics with status and duration, and enough history to know current performance. Setting a target without knowing the current number produces an SLO that is either already violated or trivially met. ## Operating Procedure 1. **Identify the user and the journey.** Who is affected, doing what? "The API" is not a journey; "a customer completing checkout" is. 2. **Choose SLIs from the user's perspective.** Measured as close to the user as practical. 3. **Measure current performance** over at least 4 weeks, including a peak period. 4. **Set the SLO just below achievable reality**, not at an aspirational number. 5. **Derive the error budget** and state what happens when it is exhausted. An SLO with no consequence is a dashboard, not a target. 6. **Write burn-rate alerts**, not threshold alerts. 7. **Review quarterly.** An