Use this when a team or organization needs to define SLAs for a service -- internal platform, customer-facing product, or vendor contract -- and needs to set appropriate targets, establish measurement methodology, and build governance for monitoring and enforcement.

Related skills: Use /instrumentation-plan for SLI/SLO technical implementation. Use /observability-plan for monitoring strategy. Use /stakeholder-comms for communicating SLA changes. Use /incident-postmortem when SLA breaches occur. SLA outputs feed into /vendor-evaluation contract terms.

Process

Step 1: Gather inputs

Collect from the service owner and stakeholders:

• Service description -- what the service does, at a technical and business level
• Consumers -- who depends on this service (internal teams, external customers, partners)
• Current reliability data -- existing uptime, latency, and error rate numbers (if available)
• Business criticality -- what happens when this service is down (revenue impact, user impact, compliance impact)
• Existing informal expectations -- what consumers already expect, even if not documented
• Contractual obligations -- any existing commitments in customer contracts or partner agreements
• Budget for reliability -- engineering and infrastructure budget available for reliability improvements

Step 2: Define SLA tiers

Classify services by criticality. Each tier gets different target levels:

Assign the service being designed to the appropriate tier. If consumers disagree on the tier, that disagreement is a useful signal -- resolve it before setting targets.

Step 3: Select metrics

For the service, choose 3-5 SLIs (Service Level Indicators) that actually matter. Don't measure everything -- measure what consumers care about.

Common SLIs by category:

For each selected metric, document:

• What exactly is measured (e.g., "HTTP 5xx responses as a percentage of total requests, excluding health checks")
• Where the measurement happens (at the load balancer, application, or client)
• Why this metric matters to consumers

Step 4: Set targets

For each metric, set targets using current baseline data and industry benchmarks:

## SLA targets -- {{service_name}}

### Availability
- **Target:** {{99.9%}} measured over {{monthly}} windows
- **Current baseline:** {{X%}} over the last {{N}} months
- **What this means:** {{43 minutes}} of allowable downtime per month
- **Exclusions:** Planned maintenance (with 72-hour notice), force majeure

### Latency
- **p50 target:** {{X}}ms
- **p95 target:** {{X}}ms
- **p99 target:** {{X}}ms
- **Current baseline:** p50={{X}}ms, p95={{X}}ms, p99={{X}}ms
- **Measurement point:** {{load balancer / application / client}}

### Error rate
- **Target:** < {{0.1%}} of requests over {{monthly}} windows
- **Current baseline:** {{X%}}
- **Definition:** HTTP 5xx responses / total responses, excluding {{exclusions}}

The cost of nines: Make this explicit in every SLA discussion.

Each additional nine costs exponentially more. The target should match the business value, not engineering pride.

Step 5: Design measurement methodology

For each metric, define:

## Measurement methodology

### {{Metric name}}
- **Data source:** {{monitoring system, logs, synthetic checks}}
- **Calculation:** {{exact formula}}
- **Reporting cadence:** {{real-time dashboard + monthly report}}
- **Measurement window:** {{calendar month, rolling 30 days}}

### Edge case handling
- **Planned maintenance:** Excluded if announced {{72}} hours in advance via {{channel}}
- **Dependent service failures:** {{Excluded / Included with note}}
- **Partial outages:** {{How degraded service is counted -- binary or proportional}}
- **Dispute resolution:** {{Who arbitrates disagreements about whether the SLA was met}}

The measurement methodology must be agreed upon before the targets are set. An SLA without clear measurement is just a hope.

Step 6: Build governance processes

## Governance

### Breach notification
- **Detection:** Automated alerting when {{metric}} crosses {{warning threshold}} (before SLA breach)
- **Notification:** {{Who is notified, through what channel, within what timeframe}}
- **Escalation:** If breach continues beyond {{X}} minutes, escalate to {{role/team}}

### Breach response
- **Incident process:** Follow standard incident management process
- **Root cause analysis:** Required for any SLA breach exceeding {{X}} minutes
- **Improvement plan:** Required if SLA is breached {{N}} times in a {{quarter}}

### Credit/penalty mechanisms (for external SLAs)
- **Breach of availability target:** {{X%}} credit on monthly invoice
- **Breach of latency target:** {{X%}} credit on monthly invoice
- **Credit cap:** {{Maximum credit per month, typically 30% of monthly fee}}
- **Claim process:** {{How customers submit claims, response timeline}}

### Regular reviews
- **Monthly:** SLA performance report to {{stakeholders}}
- **Quarterly:** SLA review meeting -- assess targets, adjust if needed
- **Annual:** Full SLA redesign review

Step 7: Generate the SLA document

# Service Level Agreement -- {{service_name}}

**Version:** {{1.0}}
**Effective date:** {{date}}
**Review date:** {{date + 1 year}}
**Owner:** {{team/person}}

## 1. Service description
{{What the service does, who it serves}}

## 2. Metrics and targets
{{From Step 4 -- metrics, targets, measurement windows}}

## 3. Measurement methodology
{{From Step 5 -- how each metric is measured}}

## 4. Exclusions
{{Planned maintenance, force majeure, dependent services}}

## 5. Breach procedures
{{From Step 6 -- notification, escalation, response}}

## 6. Credits and remedies
{{From Step 6 -- credit terms, claim process, caps}}

## 7. Review schedule
{{Monthly reporting, quarterly review, annual redesign}}

## 8. Approval
{{Signatures/approvals from service owner and key consumers}}

Step 8: Review

Before finalizing, ask:

• Are the targets achievable with current infrastructure and team capacity?
• Who pays for the additional reliability? (More nines = exponentially more cost in engineering and infrastructure.)
• Are the exclusions reasonable from the consumer's perspective?
• Does legal need to review the contract language for external SLAs?
• Is the measurement methodology automated, or does it depend on manual data collection?
• Can you actually alert on these metrics before a breach occurs?
• What happens during the first breach -- is the governance process clear enough that people know what to do?

Output location

Save to deliverables/sla-{{service_name}}-{{date}}.md. For external SLAs, the final version will likely need legal review and a different format -- this output serves as the technical foundation.