SLA / SLO / Error Budgets (SRE)
debt(d7/e7/b5/t7)
Closest to 'only careful code review or runtime testing' (d7). The detection_hints note automated=no and tools like Datadog, Prometheus, and Grafana can surface SLO breaches, but only after the system is instrumented and SLOs are defined. Misconfigurations such as measuring server uptime instead of user-facing success rate, or having no SLO definition at all, are invisible until a human audits the observability setup or users experience failures in production.
Closest to 'cross-cutting refactor across the codebase' (e7). The quick_fix requires defining SLIs, SLOs, and SLAs from user journeys and instrumenting critical endpoints. This is not a one-line patch — it involves choosing what to measure, updating monitoring pipelines, aligning contractual language, and potentially changing deployment practices (e.g. stopping maintenance from burning error budget). This touches multiple teams and systems rather than a single component.
Closest to 'persistent productivity tax' (b5). Once SLOs and error budgets are in place, every future deployment decision, incident response, and release planning session is shaped by whether the error budget is healthy or exhausted. It applies to web and API contexts broadly and imposes an ongoing operational discipline on all teams, but it does not rewrite the system's architecture — it's a governance and measurement overlay.
Closest to 'serious trap — contradicts how a similar concept works elsewhere' (t7). The misconception field is explicit: developers commonly treat SLA and SLO as interchangeable, but they are fundamentally different commitments with different audiences and consequences. The SLA should be lower than the SLO to provide a buffer, yet the common mistake listed is setting SLAs tighter than SLOs — the opposite of correct practice. This directly contradicts intuition and is a well-documented industry trap.
Also Known As
TL;DR
Explanation
Service Level Agreement (SLA): a contractual commitment to customers, often with financial penalties for breach (99.9% uptime = 8.7 hours downtime/year). Service Level Objective (SLO): an internal reliability target, more ambitious than the SLA, used to drive engineering decisions (99.95% uptime internally). Service Level Indicator (SLI): the actual measured metric (request success rate, p99 latency). Error Budget: the allowed failure headroom (100% - SLO). If the error budget is exhausted, new feature work pauses in favour of reliability improvements. For PHP applications, SLIs are defined against: HTTP success rate (non-5xx), p99 response time, and critical job completion rate.
Common Misconception
Why It Matters
Common Mistakes
- SLOs that are too tight — 99.999% uptime leaves only 5 minutes of downtime per year, making all change risky.
- Not measuring SLOs from the user's perspective — internal health checks that pass while users see errors.
- SLAs tighter than your SLOs — the SLA is what you commit to customers; your SLO should have a safety buffer.
- Burning error budget on planned maintenance — maintenance should not consume the reliability budget.
Code Examples
// No SLO — reliability managed by gut feeling:
// 'Is the site up?' → 'Seems fine'
// No data on actual uptime, latency, or error rates
// SLA commitments made without knowing if they can be met
// With SLO:
// SLO: 99.9% of requests < 500ms, error rate < 0.1%
// Error budget: 43.8 min/month
// Current burn rate: 2x — need to pause non-critical deploys# SLA / SLO / SRE — reliability engineering vocabulary
# SLI (Service Level Indicator) — what you measure
# - Availability: % of requests returning 2xx/3xx
# - Latency: % of requests < 300ms
# - Error rate: % of requests returning 5xx
# SLO (Service Level Objective) — your internal target
# - Availability: 99.5% (allows ~3.6h downtime/month)
# - Latency p99: < 500ms
# - Error rate: < 0.1%
# SLA (Service Level Agreement) — contractual commitment with consequences
# - 99.9% availability — below this triggers service credits
# Error budget:
# SLO 99.5% availability = 0.5% budget = 3.6h/month
# Burn too fast → freeze feature work, prioritise reliability
# Budget remaining → ship features confidently
# PHP monitoring stack:
# Prometheus + Grafana, Datadog, New Relic, or Laravel Telescope + Horizon