slo-architect

SLO Architect

Define SLOs that mean something. Most "SLOs" in the wild are arbitrary numbers no one believes — 99.9% on every endpoint, no SLI definition, no error budget, no policy for what happens when budget burns. This skill enforces the discipline from Google's SRE Workbook: pick the right SLI, set a target users actually care about, calculate the error budget, wire multi-window burn-rate alerts, and have a written policy for when budget runs out.

When to use

• Defining a new SLO for a service or feature
• Reviewing existing SLOs for common bugs
• Picking the right SLI (event-based vs time-window based vs request-based)
• Computing error budgets and burn-rate alert thresholds
• Tying SLOs to existing controls — feature flags abort, chaos blast radius, operator capability levels

When NOT to use

• General observability strategy (metrics + logs + traces) → use observability-designer
• Customer-facing SLAs with legal teeth → that's contract drafting, not engineering
• Performance load testing (capacity, not reliability) → use performance-profiler
• Active incident response → use incident-response

Core principle: an SLO is a promise about user experience

SLI  ⟶  measurable signal of user-perceived health (e.g., HTTP 2xx rate)
SLO  ⟶  target for the SLI over a window (e.g., 99.9% over 30 days)
SLA  ⟶  customer-facing commitment with consequences (separate concern)
EB   ⟶  error budget: 100% − SLO target = how much "bad" you can spend
BR   ⟶  burn rate: how fast you're consuming the error budget

The four cardinal mistakes:

1. Target too high (99.99%+ on services that can't support it) — every minor blip violates SLO; alerts become noise.
2. Wrong SLI (CPU usage as proxy for user experience) — system can be "green" while users suffer.
3. No error budget policy — burning budget means nothing if there's no agreed action.
4. Single-window burn-rate alert — either too noisy (page on a 5-min spike) or too slow (notice budget exhausted after the fact).