---

name: slo-designer description: Design Service Level Objectives (SLOs) with SLIs, targets, alerting thresholds, and error budget calculations following Google SRE best practices. Use when defining reliability targets, designing SLOs, calculating error budgets, or establishing service level indicators. license: MIT metadata: version: 1.0.0 model: claude-sonnet-4-5 source: Google SRE Book

SLO Designer

When this skill activates, you guide users through designing production-ready Service Level Objectives. Your role is to help identify critical user journeys, define measurable SLIs, set appropriate targets, and calculate error budgets.

Triggers

Activate when the user:

• "Design SLOs for my service"
• "Define reliability targets"
• "Calculate error budget"
• "Set up service level objectives"
• "Define SLIs for this system"
• "SLO design for API"
• "What should my availability target be?"

Core Concepts

Common SLI Categories

Availability

Percentage of successful requests.

Copyavailability_sli = (successful_requests / total_requests) * 100

Good for: APIs, web services, databases.

Latency

Response time percentiles (p50, p95, p99).

Copylatency_sli = percentile(response_times, 99)

Good for: User-facing endpoints, real-time systems.

Throughput

Requests per second (RPS) or transactions.

Copythroughput_sli = requests_per_second / expected_baseline

Good for: Batch processing, high-volume systems.

Error Rate

Percentage of 5xx responses.

Copyerror_rate_sli = (error_responses / total_responses) * 100

Good for: APIs, microservices.

Correctness

Percentage of correct results.

Copycorrectness_sli = (correct_results / total_results) * 100

Good for: Data pipelines, ML inference, calculations.

Process

Copy1. DISCOVERY          Identify critical user journeys
        |             What matters to users?
        v
2. SLI DEFINITION     Select measurable indicators
        |             How do we measure success?
        v
3. SLO TARGETS        Set achievable targets
        |             What should we promise?
        v
4. ERROR BUDGET       Calculate allowed failures
        |             How much can we fail?
        v
5. ALERTING           Define burn rate alerts
        |             When do we intervene?
        v
6. DOCUMENTATION      Generate SLO document

Scripts

calculate_error_budget.py

Calculate error budget for a given SLO target:

Copypython3 .claude/skills/slo-designer/scripts/calculate_error_budget.py \
  --target 99.9 \
  --period monthly

Arguments:

Exit Codes:

• 0: Success
• 1: Invalid arguments
• 2: Calculation error

generate_slo_document.py

Generate a complete SLO document from configuration:

Copypython3 .claude/skills/slo-designer/scripts/generate_slo_document.py \
  --config path/to/slo-config.yaml \
  --output docs/slo-document.md

Question Framework

Use these questions to gather requirements:

1. Service Context

• What is the service name and purpose?
• Who are the primary users (internal, external, both)?
• What is the business criticality (revenue impact)?
• Are there existing SLAs or customer expectations?

2. User Journeys

• What are the 3-5 most critical user journeys?
• What actions must succeed for users to be satisfied?
• What is the acceptable response time for each journey?
• Which failures are most impactful?

3. Current State

• What metrics are already collected?
• What is the current availability (if known)?
• What are the current p50, p95, p99 latencies?
• What is the current error rate?

4. Infrastructure

• What is the deployment architecture?
• Are there external dependencies?
• What is the disaster recovery capability?
• What maintenance windows exist?

5. Targets

• What availability level is appropriate?
• What latency targets align with user expectations?
• How much error budget can the team responsibly manage?
• What alerting thresholds make sense?

SLO Target Guidelines

Choosing a target:

• Start conservative (lower targets are easier to meet)
• Consider external dependencies (chain reliability)
• Account for maintenance windows
• Leave margin from SLA (SLO should be tighter)

Error Budget Table

Burn Rate Alerting

Configure alerts based on budget consumption rate:

Multi-window alerting:

CopyAlert if:
  burn_rate_1h > 14.4 AND burn_rate_6h > 6
  OR
  burn_rate_6h > 6 AND burn_rate_24h > 2

Output Template

Generate this structure:

Copy# SLO Document: [Service Name]

## Service Overview
- **Name**: [Service name]
- **Owner**: [Team name]
- **Description**: [What the service does]
- **Business Criticality**: [Low/Medium/High/Critical]

## Critical User Journeys
1. [Journey 1]: [Description]
2. [Journey 2]: [Description]
3. [Journey 3]: [Description]

## Service Level Indicators

### SLI 1: Availability
- **Definition**: Percentage of successful HTTP requests
- **Measurement**: `sum(rate(http_requests_total{status!~"5.."}[5m])) / sum(rate(http_requests_total[5m]))`
- **Data Source**: Prometheus metrics

### SLI 2: Latency
- **Definition**: 99th percentile response time
- **Measurement**: `histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))`
- **Data Source**: Prometheus metrics

## Service Level Objectives

| SLI | Target | Measurement Window | Rationale |
|-----|--------|-------------------|-----------|
| Availability | 99.9% | 30-day rolling | Industry standard for user-facing APIs |
| Latency (p99) | < 200ms | 30-day rolling | User research shows frustration above 200ms |

## Error Budgets

| SLO | Error Budget | Monthly Allowance | Current Consumption |
|-----|--------------|-------------------|---------------------|
| Availability 99.9% | 0.1% | 43 minutes | [Current] |
| Latency p99 < 200ms | 0.1% | 43 minutes | [Current] |

## Alerting Strategy

### Page-worthy Alerts (Critical)
- Burn rate > 14.4x for 1 hour AND > 6x for 6 hours
- Action: Immediate response required

### Ticket-worthy Alerts (Warning)
- Burn rate > 2x for 24 hours
- Action: Investigate within 1 business day

## Implementation Checklist
- [ ] Metrics collection configured
- [ ] SLO dashboard created
- [ ] Alerts configured
- [ ] Runbook documented
- [ ] Team trained on error budget policy

Related Concepts

SLO vs SLA

• SLO: Internal target. No contractual penalty.
• SLA: External contract. Financial consequences.
• Best Practice: SLO should be stricter than SLA to provide buffer.

Error Budget Policy

When error budget is exhausted:

1. Freeze non-critical feature work
2. Prioritize reliability improvements
3. Conduct incident reviews
4. Address technical debt

When error budget is healthy:

1. Invest in new features
2. Accept more risk
3. Run experiments

References

• Google SRE Book - SLOs
• The Art of SLOs
• Implementing SLOs