Slo Definition Workshop

---
name: slo-definition-workshop
enabled: true
description: |
  Use when performing slo definition workshop — sLO definition workflow covering
  SLI selection, target setting, error budget policy, alerting strategy, and
  stakeholder alignment. Use when establishing SLOs for a new service, revising
  existing targets, or implementing an SRE practice.
required_connections:
  - prefix: datadog
    label: "Datadog (or monitoring platform)"
config_fields:
  - key: service_name
    label: "Service Name"
    required: true
    placeholder: "e.g., checkout-api"
  - key: service_tier
    label: "Service Tier"
    required: true
    placeholder: "e.g., tier-1 (critical), tier-2 (important), tier-3 (internal)"
  - key: stakeholders
    label: "Stakeholders"
    required: false
    placeholder: "e.g., product-team, platform-team, leadership"
features:
  - SRE
  - OBSERVABILITY
---

# SLO Definition Workshop Skill

Define SLOs for **{{ service_name }}** ({{ service_tier }}).

## Workflow

### Step 1 — Service Context

Gather context about the service:

```
SERVICE PROFILE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Service: {{ service_name }}
Tier: {{ service_tier }}
Stakeholders: {{ stakeholders | "TBD" }}

User journeys this service supports:
1. [journey] — [criticality: critical/important/nice-to-have]
2. [journey] — [criticality]
3. [journey] — [criticality]

Current state:
  - Existing SLOs: YES / NO
  - Historical availability (last 30 days): ___%
  - Historical P95 latency (last 30 days): ___ms
  - Incident frequency (last 90 days): ___
```

### Step 2 — SLI Selection

Choose the right SLIs for each user journey:

```
SLI CANDIDATES
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
AVAILABILITY SLI
  Definition: Proportion of valid requests served successfully
  Formula: (successful requests) / (total valid requests) * 100
  What counts as "successful": HTTP 2xx, 3xx (exclude 4xx from denominator)
  What counts as "valid": All requests excluding health checks
  [ ] SELECTED — YES / NO

LATENCY SLI
  Definition: Proportion of requests faster than threshold
  Formula: (requests < threshold) / (total requests) * 100
  Threshold: ___ms (P50) / ___ms (P95) / ___ms (P99)
  Measurement point: [server-side / client-side / edge]
  [ ] SELECTED — YES / NO

CORRECTNESS SLI (if applicable)
  Definition: Proportion of requests returning correct results
  Formula: (correct responses) / (total responses) * 100
  How "correct" is defined: [validation method]
  [ ] SELECTED — YES / NO

FRESHNESS SLI (for data pipelines)
  Definition: Proportion of data updated within threshold
  Formula: (records updated within X min) / (total records) * 100
  Freshness threshold: ___ minutes
  [ ] SELECTED — YES / NO

THROUGHPUT SLI (if applicable)
  Definition: Proportion of time throughput is above minimum
  Formula: (minutes above threshold) / (total minutes) * 100
  Minimum throughput: ___ rps
  [ ] SELECTED — YES / NO
```

### Step 3 — SLO Target Setting

```
SLO TARGETS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
| SLI | Target | Window | Rationale |
|-----|--------|--------|-----------|
| Availability | ___% | 30 days rolling | [why this target] |
| Latency (P95) | ___% < ___ms | 30 days rolling | [why this target] |
| Latency (P99) | ___% < ___ms | 30 days rolling | [why this target] |
| [Other SLI] | ___% | 30 days rolling | [why this target] |

GUIDANCE BY TIER:
  Tier 1 (critical): 99.9% availability (43 min/month budget)
  Tier 2 (important): 99.5% availability (3.6 hrs/month budget)
  Tier 3 (internal): 99.0% availability (7.2 hrs/month budget)

IMPORTANT: SLO should be achievable but aspirational.
  - Too aggressive: constant alert fatigue, team burnout
  - Too lenient: users experience poor reliability before SLO violation
  - Rule of thumb: set slightly above historical performance
```

### Step 4 — Error Budget Policy

```
ERROR BUDGET POLICY
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
30-day error budget for {{ service_name }}:

| SLO Target | Budget (minutes/month) | Budget (requests/month*) |
|-----------|----------------------|------------------------|
| 99.99% | 4.3 min | 0.01% of requests |
| 99.9% | 43.2 min | 0.1% of requests |
| 99.5% | 216 min (3.6 hrs) | 0.5% of requests |
| 99.0% | 432 min (7.2 hrs) | 1.0% of requests |

BUDGET STATES AND ACTIONS:
  Budget > 50% remaining:
    [ ] Normal development velocity
    [ ] Feature work prioritized
    [ ] Experimentation encouraged

  Budget 20-50% remaining:
    [ ] Increased caution with risky changes
    [ ] Reliability improvements prioritized alongside features
    [ ] Review recent incidents for patterns

  Budget < 20% remaining:
    [ ] Feature freeze for this service
    [ ] All engineering effort on reliability
    [ ] Incident review required for every budget-consuming event

  Budget exhausted (0%):
    [ ] Full feature freeze
    [ ] Mandatory reliability sprint
    [ ] Executive review of service health
    [ ] Postmortem required before resuming feature work

BUDGET RESET: Monthly rolling window
```

### Step 5 — Alerting Strategy

```
SLO-BASED ALERTING
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Multi-window, multi-burn-rate alerting:

FAST BURN (page immediately):
  - Window: 5 min
  - Burn rate: 14.4x (exhausts 30-day budget in 2 days)
  - Action: PAGE on-call

SLOW BURN (ticket within hours):
  - Window: 6 hours
  - Burn rate: 6x (exhausts budget in 5 days)
  - Action: PAGE on-call during business hours

STEADY BURN (ticket):
  - Window: 3 days
  - Burn rate: 1x (on track to exhaust budget)
  - Action: CREATE TICKET, review in next sprint

[ ] Alerts configured in monitoring platform
[ ] Alert routing configured (PagerDuty / OpsGenie)
[ ] Runbook linked to each alert
```

### Step 6 — Documentation & Alignment

```
SLO DOCUMENT
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] SLO document published (wiki / repo)
[ ] Stakeholders reviewed and approved targets
[ ] Dashboard created showing SLO status and error budget
[ ] Error budget policy agreed upon with product team
[ ] Review cadence set: [monthly / quarterly]
[ ] First review date: [date]
```

## Counter-Rationalizations

| Shortcut | Counter | Why |
|----------|---------|-----|
| "We can skip some steps for this case" | Adapt the workflow steps, don't skip them | Skipped steps are where incidents and oversights originate |
| "The user seems to already know what to do" | Complete all workflow phases with the user | The workflow catches blind spots that experience alone misses |
| "This is a minor case, full process is overkill" | Scale the process down, don't turn it off | Minor cases become major when unstructured; the process scales, not disappears |
| "I'll fill in the details later" | Complete each section before moving on | Deferred details are forgotten; real-time capture is more accurate |
| "The template output isn't necessary" | Always produce the structured output format | Structured output enables comparison, audit trails, and handoff to other teams |

## Output Format

Produce an SLO definition document with:
1. **Service context** (name, tier, user journeys)
2. **SLI definitions** with measurement methodology
3. **SLO targets** with rationale
4. **Error budget** calculations and policy
5. **Alerting configuration** with burn-rate thresholds
6. **Stakeholder sign-off** tracker