Problem
'The system should be reliable' is not actionable. Teams argue about priorities. Reliability work never gets scheduled.
observabilityestablished · medium operational burden
SLI / SLO / Error Budgets
Also known as: service-level-indicator, service-level-objective, error-budget
Intent
Define reliability in business terms: what to measure (SLI), what's acceptable (SLO), and how much unreliability you can spend (error budget).
Forces
- •Reliability is a feature with cost and trade-offs
- •Business and engineering speak different languages
- •Need quantitative basis for prioritization
- •100% reliability is impossible and wasteful
Solution
✓ When to Use
- •Any service with reliability requirements
- •Teams arguing about reliability vs features
- •Need data-driven prioritization
✗ When Not to Use
- •Pre-product-market fit (no users to disappoint)
- •Internal tools with no SLA
- •Team not ready for measurement discipline
Pros
- +Common language: business ↔ engineering
- +Prioritization: error budget = currency
- +Alerting: actionable, not noisy
- +Culture: reliability as feature, not chore
Cons
- −Measurement investment: SLI implementation
- −SLO setting: art + science, easy to get wrong
- −Gaming: relax SLO to ship features
- −Organizational: requires leadership buy-in
Cost Profile
Infrastructure
Low — metrics, alerting
Operational
Medium — SLO review, burn rate tuning
Cognitive
Medium — SLI design, budget thinking
Failure Modes
Vanity SLOs: easy to meet, don't reflect user pain
SLO theater: measured but not used for decisions
Burn rate alerting: too sensitive (noise) or too slow (miss)
Error budget hoarding: never spend, reliability over-invested
Real-World Examples
Alternatives
- uptime-monitoring
- threshold-alerting
- availability-targets
Related Patterns
- observability
- error-budget
- burn-rate-alerting
- reliability
- metrics
Competency Domains
reliability opseconomics evolutiondistribution communicationdeployment