# Slo Architect > SLO design: define SLIs, set reliability targets, calculate error budgets, design alerting policies, build runbooks — Google SRE methodology - Skill: `uitbreidenos/slo-architect` (Agent Skill) - Install (CLI): `npx skillmds@latest add uitbreidenos/slo-architect` - Raw SKILL.md: https://api.skillmd.com/api/skills/uitbreidenos/slo-architect/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: DevOps & Infra - Author: UitbreidenOS (https://skillmd.com/u/uitbreidenos) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/uitbreidenos/slo-architect --- # SLO Architect Skill ## When to activate - Defining Service Level Objectives (SLOs) for a service - Calculating error budgets and setting burn rate alerts - Moving from reactive "is it up?" monitoring to proactive SLO-based alerting - Writing SLAs for customers based on internal SLOs - Building a reliability culture from scratch ## When NOT to use - Specific monitoring tool configuration (use tool docs for Prometheus/Datadog syntax) - Incident response procedures — use the runbook skill - Pure uptime monitoring — Uptime Robot is simpler for basic checks ## Instructions ### Define SLIs (Service Level Indicators) ``` Define SLIs for this service. Service: [describe — API / web app / data pipeline / payment processor] Users: [who depends on this service?] What "working" means to users: [their experience when things are good] Common SLI types: 1. Availability: % of time the service is reachable Measurement: successful requests / total requests 2. Latency: how fast responses come Measurement: % of requests completing under threshold (e.g. p99 < 200ms) 3. Error rate: % of requests that fail Measurement: error responses / total responses 4. Throughput: capacity to handle load Measurement: requests processed per second 5. Data freshness: how stale is the data? Measurement: % of queries returning data < X minutes old 6. Correctness: are results accurate? Measurement: % of outputs matching expected (requires synthetic probing) For my service, define 2-4 SLIs with exact measurement formulas. ``` ### Set SLO targets ``` Help me set appropriate SLO targets. Service criticality: [critical / important / internal-only] Current reliability baseline: [uptime / error rate over last 90 days] Business impact of downtime: [describe — revenue loss / customer impact] Team maturity: [no SRE / small SRE team / experienced SRE] SLO target guidance: - 99% (2 nines): ~7.3 hours downtime/month — OK for internal tools - 99.5%: ~3.6 hours downtime/month — typical B2B SaaS - 99.9% (3 nines): ~43 minutes downtime/month — standard for customer-facing - 99.95%: ~21 minutes — high-reliability expectation - 99.99% (4 nines): ~4.3 minutes — payments, healthcare, critical infrastructure Rule: SLO should be achievable but meaningful. Never set 100% — it's unachievable and creates wrong incentives. For my service: what SLO target is appropriate and why? ``` ### Error budget calculation ``` Calculate error budget for these SLOs. SLO 1: [metric] = [X]% over [28 days / calendar month / rolling] SLO 2: [metric] = [X]% Error budget = 1 - SLO target For 28-day window: - 99.9% SLO → 0.1% error budget = 40.3 minutes of downtime allowed - 99.5% SLO → 0.5% error budget = 3.36 hours allowed Current error budget consumption: - How much budget have we used so far this period? [%] - How many days remain in the period? - Are we on track to stay within budget? If over budget: what should we stop doing (new feature launches) until budget recovers? If under budget: what risk can we take on (planned maintenance, experiments)? ``` ### Alerting design (burn rate alerts) ``` Design burn rate alerts for this SLO. SLO: [X]% availability over 28 days Error budget: [calculated above] Alerting strategy (Google SRE handbook): 1. Fast burn (critical): consuming budget 14x faster than normal → Fires in: 1 hour of sustained burn → Alert: page immediately, this will exhaust budget in ~2 days 2. Slow burn (warning): consuming budget 6x faster than normal → Fires in: 6 hours of sustained burn → Alert: ticket, review at next standup, not a wake-up call 3. Budget at X%: absolute threshold alert → When 50% of budget is consumed in the first 14 days → Alert: "on track to exhaust budget, review velocity" For my SLO, generate: - Alert thresholds (actual numbers, not X) - Alert names and severity levels - On-call escalation policy - Runbook reference for each alert type ``` ### SLO dashboard design ``` Design an SLO dashboard for [service]. Key stakeholders viewing this: - Engineering: need to see error budget and burn rate - Product: need to see reliability trends, impact on users - Leadership: need overall health, nothing too technical Dashboard sections: 1. Current SLO status: green/yellow/red for each SLO 2. Error budget remaining: gauge chart, % remaining this period 3. Burn rate: 1-hour and 6-hour burn rate vs. target 4. Historical trend: 90-day SLO performance 5. Incident correlation: recent incidents and their budget impact Tools: [Grafana / Datadog / Google Cloud Monitoring / New Relic / Honeycomb] ``` ## Example **User:** I have a REST API used by paying customers. No SLOs currently, just "is it up" alerting. Where do I start? **Claude's SLO starter pack:** **Step 1 — Define 3 SLIs:** - Availability: `successful_requests / total_requests` (exclude 400s, count 500s + timeouts as failures) - Latency: `p99_response_time < 500ms` as a ratio of all requests - Error rate: `5xx_responses / total_responses` **Step 2 — Set initial SLO targets (conservative):** - Availability: 99.5% (3.6 hours budget/month) - p99 latency: 99% of requests under 500ms - Error rate: < 0.5% **Step 3 — One alert to start:** Burn rate alert: if availability drops below 99.5% for 1 hour straight → page the on-call engineer. **Step 4 — Review in 90 days:** Look at actual performance vs. SLO. If you never used error budget, the target may be too loose. If you're constantly over, the target needs adjustment or investment. ---