| name | slo-architect |
| description | Use when defining, reviewing, or operating SLOs/SLIs/error budgets. Triggers on "define an SLO", "what should our SLO be", "error budget", "burn rate", "SLI", "service level objective", "Google SRE workbook", "multi-window burn-rate alert", or any reliability-target question. Ships SLO designer, error-budget calculator with multi-window burn-rate thresholds, and SLO reviewer that catches the common bugs (target too aggressive, window too short, conflicting SLOs, no SLI definition). 4 references on SLO principles + SLI design + error budget math + composition with feature-flags-architect/chaos-engineering/kubernetes-operator. NOT a generic observability skill — specifically the SLO discipline. |
| context | fork |
| version | 2.9.0 |
| author | claude-code-skills |
| license | MIT |
| tags | ["slo","sli","sla","error-budget","burn-rate","sre","reliability","google-sre-workbook","observability"] |
| compatible_tools | ["claude-code","codex-cli","cursor","antigravity","opencode","gemini-cli"] |
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:
- Target too high (99.99%+ on services that can't support it) — every minor blip violates SLO; alerts become noise.
- Wrong SLI (CPU usage as proxy for user experience) — system can be "green" while users suffer.
- No error budget policy — burning budget means nothing if there's no agreed action.
- Single-window burn-rate alert — either too noisy (page on a 5-min spike) or too slow (notice budget exhausted after the fact).
The 3 tools below catch each of these.
Quick start
SKILL=engineering/slo-architect/skills/slo-architect
python "$SKILL/scripts/slo_designer.py" \
--service checkout-svc \
--sli-type request-success-rate \
--target 99.9 \
--window-days 30
python \
--target 99.9 --window-days 30
python --slo-doc docs/slos/
