SLO Error Budget Mapping
SLO error budget mapping converts the reliability target into a concrete budget of allowed failures per window, so "99.9%" becomes "43 minutes per month" that a team can spend and track.
Definition
SLO error budget mapping is the practice of converting a service level objective — e.g., 99.9% success over 30 days — into the concrete budget of allowed failures (43.2 minutes of downtime or 0.1% of requests) that the team can spend on features, freeze for stability, or burn down, making the SLO actionable.
Context and scope
Applied in SRE programs, platform teams, and any organization that uses error budgets to gate feature velocity against reliability.
Common misconceptions
- The error budget is just 100% minus the SLO — it is, but the value is in the per-window budget and the burn rate that tells you when you will exhaust it
- A high SLO is always better — a higher SLO is more reliable and more expensive; the right SLO is the one the user is satisfied with at the cost the business can afford
Anti-patterns
- Setting an SLO without measuring whether users are satisfied at that level, optimizing for a number that does not match the experience
- Burning the budget and resetting it without consequence, so the budget is a tracked number that never gates anything
Related concepts
Authoritative source
What it is
SLO error budget mapping is the practice of converting a service level objective — e.g., 99.9% success over 30 days — into the concrete budget of allowed failures (43.2 minutes of downtime or 0.1% of requests) that the team can spend on features, freeze for stability, or burn down, making the SLO actionable. Applied in SRE programs, platform teams, and any organization that uses error budgets to gate feature velocity against reliability. The goal is not to collect all data but to be able to answer the question you did not think to ask in advance — which requires high-cardinality labels and exemplars that link traces to the metric that triggered them.
How it works
Three signals compose: metrics aggregate over time, traces preserve causality across boundaries, and logs carry the unstructured detail. Sampling is adaptive — head sampling for known-interesting paths, tail sampling to retain slow or error traces at a fixed budget. Cardinality is controlled at the source, not the query, because a high-cardinality label explodes storage and makes dashboards unusable.
When to invest and pitfalls
Invest when mean time to detect matters — in production, at scale, with paying users. The pitfall is instrumenting everything and alerting on nothing: dashboards full of lines that no one reads, alerts that fire on noise and are then muted, leaving the real outage undetected. Symptom-based alerts on user-visible degradation outperform cause-based alerts on internal thresholds.