Setting SLO targets
How ambitious to be — windows, percentiles, and targets grounded in history and product risk.
An SLO target is a product decision dressed as a number. Too tight and you freeze forever; too loose and users leave before you page.
Start from data and stakes
Look at recent SLI history and customer impact. A new service with no history still needs a provisional target — mark it provisional and revisit after a month of truth.
Higher stakes (payments, auth) justify tighter objectives and more engineering cost. Internal tools can be looser if the business agrees.
Windows matter
Common windows: rolling 28 or 30 days. Shorter windows react faster; longer windows smooth noise. Multi-window views help: a bad hour can burn budget without ending the month.
Percentiles over averages
Average latency hides the users in the tail. Prefer p95/p99 (or histogram-based thresholds) aligned with how slow feels unacceptable.
Fewer, owned targets
Each SLO needs an owner who can spend budget and stop releases. Orphan SLOs become wallpaper.
Iterate in public
Publish targets where the team sees them. When you change a target, record why — silent loosening after every incident is how standards die.