SLO Design
Design first SLOs for a service: exact SLI specs, history-based targets, dependency math, error budgets, and a budget policy.
Before & after
Same prompt, same agent — the only difference is the skill.
Reliability is important. You'll want to think about what acceptable downtime looks like for your service. Different services have different requirements depending on their criticality. You might measure things like uptime percentage or response time. Setting targets is helpful for your team. You could look at what industry standards are. Think about the impact of outages on your business. It's worth discussing with your team what matters most. There are various metrics you could track.
SLO DESIGN FRAMEWORK STEP 1: Classify your service (by customer impact) TIER 1 - Critical (revenue-blocking): 99.95% SLA required TIER 2 - Important (features): 99.5% SLA required TIER 3 - Nice-to-have (admin): 99% SLA required Your service: TIER 2 (booking calendar, non-revenue-blocking but core feature) STEP 2: Define SLI (what you'll measure) For booking calendar: SLI 1: Availability = Successful requests / Total requests (target: 99.5%) SLI 2: Latency = Response time p99 < 500ms (target: 95% of requests) STEP 3: Translate to SLO (what you promise) SLO: Maintain 99.5% availability + p99 latency under 500ms, measured monthly Error budget: 0.5% × 43,200 minutes/month = 216 minutes (3.6 hours) downtime allowed STEP 4: Allocate error budget across causes Infrastructure outages: 120 min budget Deployment failures: 60 min budget Data corruption/rollback: 20 min budget Wildcard/unplanned: 16 min budget STEP 5: Monitoring gates Alert at 80% error budget consumed (in-month) Freeze deployments at 90% consumed Post-mortem required for any breach STEP 6: Fallback behavior If calendar booking fails, show cached 24-hr history → graceful degradation, not failure REVISION CADENCE: Quarterly review; adjust if error budget consistently unused (loosen SLO) or breached (tighten/invest)
About this skill
First SLOs usually fail on details: undefined good events, latency on averages, targets copied from a blog, and budgets with no policy. This skill designs SLOs a team can actually measure and act on.
What it does
- Maps critical user journeys to 1-3 SLIs each from a menu (availability, latency, freshness, correctness, coverage)
- Writes SLI specs and implementations separately, with valid-event rules and measurement point limits
- Derives targets from history and dependency math, and converts them to minutes and requests of budget
- Covers low-traffic services, batch pipelines, and LLM or agent features
- Includes an error budget policy with thresholds and a decider
What you get
An SLO table (spec, implementation, target, window, budget, basis), a dependency ceiling check, an error budget policy, and gaps to instrument.
Best for
Engineering teams launching a new service or setting reliability targets for the first time.
SKILL.md preview
---
name: slo-design
… (sign up to view the full skill)More development skills
View all Development skills →Chaos Experiment and Game Day Planner
Plans chaos experiments and game days: hypothesis, blast radius, abort conditions, tool manifests, rollback, and post-run review.
Claude Code Cost and Latency Routing
Configure Claude Code Router with model tiers, explicit fallbacks, compatibility checks, and a cost-aware validation plan.
CI/CD Pipeline Builder with Gated Deploys
Generates CI/CD workflows from your repo's real stack: cached fast-fail checks, pinned actions, and staging-to-prod deploys with gates.
Terraform Modules and Safe Deployments
Get reusable Terraform modules, safe state migrations, explicit provider wiring, and CI gates tied to reviewed plans.