design-slo-sla-framework

name	design-slo-sla-framework
description	Use when establishing reliability targets for services, defining error budgets for engineering teams, or negotiating service commitments with customers
source	Google SRE Workbook (2018) Ch. 2; Beyer et al. "Site Reliability Engineering" (2016); Treynor "The Calculus of Service Availability" Queue (2017)
tags	["reliability","sre","slo","observability"]
verified	true

Design SLO/SLA Framework

Define Service Level Objectives (SLOs) that balance reliability with feature velocity, and Service Level Agreements (SLAs) that set customer expectations with contractual consequences.

Why This Is Best Practice

Adopted by: Google (SRE origin), Atlassian, Spotify, Cloudflare, AWS (every managed service has published SLAs) — the SRE discipline is built on this foundation Impact: Google SRE book: teams using error budgets ship 2x more features with 2x fewer incidents; SLOs replace "keep the lights on" with measurable, negotiable reliability targets; error budgets make reliability vs. velocity trade-offs explicit and data-driven Why best: Without SLOs, reliability is subjective; "the system is unreliable" vs. "we missed our 99.9% availability SLO by 0.2% this month" — the latter drives precise conversations and improvement

Sources: Beyer et al. "Site Reliability Engineering" O'Reilly (2016); Murphy et al. "The Site Reliability Workbook" O'Reilly (2018); Treynor "The Calculus of Service Availability" ACM Queue (2017)

Steps

1. Define SLIs (Service Level Indicators) — An SLI is a quantitative measure of the service's behavior from the user's perspective. Common SLIs: availability (successful requests / total requests), latency (% of requests completing < threshold), throughput (requests processed per second), error rate (failed requests / total requests). Choose SLIs that reflect what users care about, not what's easy to measure.

2. Set SLO targets — An SLO is a target range for an SLI over a time window. "99.9% of requests succeed over a rolling 30-day window." The target must be aspirational but achievable. Start with historical performance and set the SLO at the 10th percentile of recent 30-day windows. Tighten over time as reliability improves.

3. Calculate error budgets — Error budget = 1 - SLO. For 99.9% availability: error budget = 0.1% of requests = 43.2 minutes of downtime per 30-day window. The error budget is the allowable unreliability. Track budget consumption daily. When the error budget is exhausted, reliability work takes priority over feature development.

4. Define the SLO measurement window — Rolling windows (last 30 days) are more stable than calendar windows and avoid the "reset on the 1st" gaming problem. Use a 28-day or 30-day rolling window for most SLOs. Weekly SLOs are useful for fast feedback but noisy; use as leading indicators, not commitments.

5. Choose SLO tiers for service criticality — Tier 1 (user-facing critical): 99.9% or 99.95% availability, p99 < 200 ms. Tier 2 (internal business logic): 99.5%, p99 < 500 ms. Tier 3 (batch, background): 99.0%, no latency SLO. Not all services need the same reliability target; higher SLOs cost proportionally more to maintain.

6. Implement SLO monitoring — Measure SLIs continuously. Use Prometheus + Grafana, Datadog SLO tracking, or Google Cloud Monitoring. Alert at 2% and 5% of monthly error budget consumed in the last hour (alert on burn rate, not remaining budget). Burn rate alerting provides time to act before the budget is exhausted.

7. Define SLAs (Service Level Agreements) — An SLA is a commercial agreement with defined consequences for missing the SLO (service credits, refunds). SLAs must be weaker than SLOs: if your SLO is 99.9%, your SLA should commit to 99.5% — the gap is your margin for SLO misses before SLA consequences trigger. Involve legal and product in SLA definition.

8. Establish error budget policy — Write and publish: when the error budget is > 50% remaining: normal development velocity. When 25-50% remaining: reliability review required before major deployments. When < 25% remaining: freeze feature deployments; focus on reliability. When exhausted: full reliability incident review; no feature work until budget is replenished.

Rules

• SLOs must be set based on user needs, not technical limitations; "this is the best we can do" is not a user-centered SLO.
• The error budget policy must have organizational authority; a VP overriding the error budget freeze defeats the system.
• SLAs must always be weaker than SLOs; promising customers what you haven't achieved internally guarantees SLA violations.
• Burn rate alerting is mandatory; alerting only when the budget is nearly exhausted gives no time to remediate.

Common Mistakes

• Setting 100% SLO targets — 100% is unachievable; it eliminates the error budget and forces all incidents to be crises; 99.9% is the standard for high-availability user-facing services.
• Measuring from infrastructure metrics instead of user perspective — server uptime ≠ user-experienced availability; measure from the user's perspective (successful API responses, successful page loads).
• No error budget policy enforcement — SLOs without consequences for consumption are aspirational metrics, not reliability management; the error budget policy gives SLOs teeth.
• Too many SLOs — 20+ SLOs per service creates alert fatigue; focus on 2-3 SLIs per service that most directly reflect user experience.

When NOT to Use

• Internal developer tools with no external SLAs and where developers can tolerate occasional downtime
• Experimental or prototype services not yet serving production user traffic
• Batch systems where availability and latency SLOs are meaningless; use throughput and completion-time SLOs instead