SLO setup: pick the type, set burn-rate alerts, test them

# SLO setup that survives contact with reality

## Pick the type

- **Metric SLO**: you have good/bad event counts as metrics (request counts, error counts). Most flexible, most work: you write the numerator/denominator queries.
- **Monitor-based SLO**: you already have a monitor that defines bad. Fastest path, inherits the monitor quirks (fix the monitor first).
- **Time-slice SLO**: good/bad minutes from metrics. Best for availability-style objectives with clear per-minute verdicts.

## The setup flow

1. **Target**: 99, 99.5, 99.9, pick from the business, not from ambition. Each nine roughly 10xes the engineering cost.
2. **Window**: 7, 30, or 90 days rolling. Shorter windows react faster and noisily; 30d is the sane default.
3. **Name, description, tags**: name it for the user experience it protects, describe why it matters, tag `team` and `service` so the SLO list is searchable.
4. **Thresholds**: target plus a warning threshold above it (warning fires before the objective is breached).
5. **Burn-rate alerts**: alert on budget consumption rate, not on the raw error ratio. A fast-burn alert (1h window) pages; a slow-burn alert (6h+) tickets. Tune the windows to your traffic: low-traffic services need longer windows or one bad minute pages you.

## Traps

- SLO on a metric that changes tags next quarter. The query silently stops matching and the SLO goes green forever. Review SLO queries like code.
- Alerting on the SLI directly instead of burn rate: you get paged for blips that consume 0.1 percent of budget.
- Too many SLOs. Five SLOs per service that nobody looks at lose to one SLO the team actually defends in review.

## Verify

Burn a little budget on purpose in staging (synthetic errors) and watch the fast-burn alert fire and the SLO view reflect it. An SLO whose alert you have never seen fire is untested.