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