---
name: slo-architect
description: "SLO design: define SLIs, set reliability targets, calculate error budgets, design alerting policies, build runbooks — Google SRE methodology"
---

# 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.

---

> **Work with us:** Claudient is backed by [Uitbreiden](https://uitbreiden.com/) — we build AI products and B2B solutions with developer communities.
> [uitbreiden.com](https://uitbreiden.com/) · [Reddit](https://www.reddit.com/r/uitbreiden/) · [YouTube](https://www.youtube.com/@UITBREIDEN)
