Most SLOs are picked because 99.9% sounds respectable, then never referenced again. An SLO is only useful if a specific number of bad minutes triggers a specific decision, so this worksheet makes you write the error budget policy before you pick the target.
Write the SLI as a ratio of events, not an average. Averages hide the failures you care about. Define good events over valid events: successful requests over all requests that reached your service. Be explicit about what is excluded: health checks, bot traffic, requests rejected for bad input you cannot control.
Pick the target from the budget it buys, not from how it reads. 99.9% over 30 days is 43 minutes of failure. 99.99% is 4.3 minutes, less than a single deploy gone wrong. Work out what your team can actually hold, then set the number. Choosing 99.99% because it looks serious commits you to a reliability budget nobody has agreed to fund.
Write the policy before anyone has spent the budget. The error budget policy is the whole point: when the budget is exhausted, what stops? Feature deploys pause, reliability work takes priority, and the decision is automatic rather than negotiated. Writing it after the budget is gone means writing it during an argument.
Alert on burn rate across two windows. A single threshold either pages constantly or notices too late. Pair a fast window with a slow one: a 14.4x burn over one hour means you will exhaust a 30-day budget in roughly two days, which deserves a page. A 1x burn over six hours is a ticket.
Here's a preview. Unlock the free download to get all 7 sections (6 more below).
One worksheet per user journey, not per service. Users experience journeys; your org chart is irrelevant to them.
More free templates IT teams use alongside this one.
A runbook is read by a tired person at 03:00 who did not write it and does not know this service. That single constraint rules out most of what people put in runbooks: architecture background, rationale, and anything written in prose when it could have been a command.
Most postmortems produce a document nobody reads and actions nobody owns. This one forces the three things that actually reduce repeat incidents: a timeline built from timestamps rather than memory, contributing factors stated without naming a person, and action items with an owner and a date.
Most severity matrices fail in the one moment they matter: at 02:00, when a tired engineer has to decide whether to wake anyone. This one is written so the level is readable off customer impact alone: no judgement call about root cause, no guessing how bad it might get.
An SLI is the measurement, the ratio of good events to valid events. An SLO is the internal target for that measurement. An SLA is an external commitment, usually with financial consequences. Set your SLO tighter than any SLA so you have warning before a contractual breach.
Measure your current attainment over at least 30 days, then set the target at or slightly above it. Check what budget the target buys: 99.9% allows 43 minutes of failure per 30 days, 99.99% allows 4.3 minutes. Pick the number your team can hold, not the one that reads best.
A pre-agreed statement of what changes as the error budget is consumed: typically pausing feature deploys once consumption passes a threshold, and freezing non-reliability change when the budget is exhausted. Without it, an SLO is a measurement that does not alter anyone's priorities.
Alerting on how fast you are consuming the error budget rather than on whether the SLO has already been missed. A 14.4x burn rate sustained over an hour means a 30-day budget disappears in about two days. Pairing a short and a long window keeps the alert both fast and quiet.
