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.