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

TL;DR

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. Fastest path, inherits the monitor quirks (fix the monitor first). - Time-slice SLO: good/bad minutes from metrics. Target: 99, 99.5, 99.9, pick from the business, not from ambition. Each nine roughly 10xes the engineering cost.

When to use

You are seeing this: Most flexible, most work: you write the numerator/denominator queries. - Monitor-based SLO: you already have a monitor that defines bad. Use this skill when you run into "SLO setup: pick the type, set burn-rate alerts, test them".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

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.

The SLO API docs define the allowed types (metric, monitor, time_slice) with thresholds, timeframes (7d/30d/90d), and targets; the SLO checklist guide walks through target selection (99, 99.5, 99.9), time windows, naming, description, and team/service tags. Verified against live docs 2026-09-26.