Skip to content
man glossary/error-budget

glossary define error-budget

Name

Error Budget

The amount of failure an SLO allows over its window (100% minus the target), spent by incidents and used to decide when to slow releases down.

Synopsis

SLO error budget, Burn rate, Reliability budget

Section

Reliability & scale

Level

practitioner

▍

Reviewed

Watch a 28-day budget get spent

5 / 5
025507510040%
  • Release freeze0–25%
  • Ship with care25–50%
  • Ship freely50–100%
Reading 5 of 5Ship with care

Day 38: window rolls on

40%

The day-9 burst ages out of the 28-day window and the retry fix holds. Budget back above 25%, so releases resume with care.

An illustrative month for a 99.5% OTP-send SLO. Step through the incidents to see how much budget each burns, when the freeze policy kicks in and how the rolling window recovers.

Day 38: window rolls on: 40% — Ship with care zone. The day-9 burst ages out of the 28-day window and the retry fix holds. Budget back above 25%, so releases resume with care.

Description

What is an error budget?

An error budget is the amount of unreliability a Service Level Objective (SLO) permits over its measurement window. If the SLO says 99.5% of OTP sends must be accepted by the Cloud API within two seconds over 28 days, the error budget is the remaining 0.5%: out of 1,200,000 sends in that window, up to 6,000 may be slow or fail before the objective is missed.

The budget turns a reliability target into a decision tool. While budget remains, the team can ship features, run experiments and take planned maintenance; incidents, bad deploys and upstream failures spend it. When it is nearly gone, an agreed error budget policy kicks in, typically freezing risky releases and redirecting engineering time to reliability work until the budget recovers as old failures roll out of the window.

Teams watch how fast the budget is being spent with the burn rate: the current error rate divided by the error rate the SLO allows. A burn rate of 1 uses the budget exactly by the end of the window; a burn rate of 10 on a 99.5% SLO (5% of sends failing) would empty a 28-day budget in under three days. Alerting on burn rate pages people for problems that threaten the objective and ignores brief blips that do not; how those pages are designed (window pairs, minimum traffic, routing) belongs to alerting, while the budget supplies the number they measure.

An error budget is not a metric of its own. The Service Level Indicator (SLI) is the measured ratio of good events, the SLO is the target set on it, and the error budget is the room between the two. It is also not an SLA credit: credits are a contractual penalty owed to customers, while the budget is an internal planning tool.

Key takeaways

  • An error budget is 100% minus the SLO: a 99.5% target allows 0.5% of events, or 0.5% of the time, to be bad in the window.
  • A 99.9% target over 30 days allows 43.2 minutes of full outage; 99.5% over 28 days allows about 3 hours 22 minutes.
  • Burn rate is the observed error rate divided by the budget rate; a burn rate of 1 spends the budget exactly over the window.
  • Page on fast burns (14.4x over an hour spends 2% of a 30-day budget) instead of on raw error spikes.
  • The budget only works with a written policy: when it runs out, risky releases pause until reliability recovers.

Properties

An error budget: key facts and limits

Formula
Error budget = 1 - SLO target
99.9% over 30 days
43.2 minutes of full outage
99.5% over 28 days
About 3 h 22 min, or 5 bad events per 1,000
Burn rate
Observed error rate / (1 - SLO)
Fast-burn page
14.4x over 1 h = 2% of a 30-day budget
Slow-burn page
6x over 6 h = 5% of a 30-day budget
Ticket, not page
1x over 3 days = 10% of a 30-day budget

Mechanics

How does an error budget work?

  1. step 1 — Start from an SLO

    Pick the SLI (for example, OTP sends returning a wamid within two seconds), the target (99.5%) and the window (28 days, rolling). The budget is 1 minus the target.

  2. step 2 — Convert it into events or minutes

    Event-based: budget = (1 - SLO) x valid events, so 0.005 x 1,200,000 = 6,000 bad sends. Time-based: 0.005 x 672 hours is about 3 hours 22 minutes of downtime.

  3. step 3 — Track spend and burn rate

    Each bad event spends budget. Burn rate = (bad / total in a recent period) / (1 - SLO); dashboards show both the share of budget remaining and how fast it is going.

  4. step 4 — Alert on burn, not on blips

    Use multi-window burn-rate alerts: page when both a long and a short window burn fast (14.4x over 1 hour and 5 minutes), ticket when a slow burn persists (1x over 3 days).

  5. step 5 — Apply the policy

    When remaining budget falls below the agreed threshold, freeze feature releases, require a canary release for any change, and prioritise the fixes from the incident review.

Usage

An error budget in code

groups:
  - name: otp-send-slo            # SLO: 99.5% good over 28 days, budget rate 0.005
    # 14.4x and 6x are the SRE Workbook's factors for a 30-day window; close enough for 28 days.
    rules:
      - alert: OtpSendBudgetFastBurn
        expr: |
          (
            sum(rate(otp_sends_total{result="bad"}[1h]))
              / sum(rate(otp_sends_total[1h]))
          ) > (14.4 * 0.005)
          and
          (
            sum(rate(otp_sends_total{result="bad"}[5m]))
              / sum(rate(otp_sends_total[5m]))
          ) > (14.4 * 0.005)
        labels:
          severity: page
        annotations:
          summary: "OTP sends are burning the error budget 14x faster than the SLO allows"
      - alert: OtpSendBudgetSlowBurn
        expr: |
          (
            sum(rate(otp_sends_total{result="bad"}[6h]))
              / sum(rate(otp_sends_total[6h]))
          ) > (6 * 0.005)
          and
          (
            sum(rate(otp_sends_total{result="bad"}[30m]))
              / sum(rate(otp_sends_total[30m]))
          ) > (6 * 0.005)
        labels:
          severity: page

Long window proves the burn is real, short window proves it is still happening, so alerts stop soon after recovery.

Caveats

Common mistakes with an error budget

  • A budget with no policy

    If nothing changes when the budget runs out, it is just another chart. Write down, before the next incident, who decides, what freezes, and what lets releases resume, and get product and engineering leads to sign it.

  • Setting the SLO at 100%

    A 100% target leaves zero budget, so every deploy is a violation and the number is ignored. Choose the lowest target customers would not notice, and tighten it only when they would.

  • Quietly excluding upstream outages

    Leaving Meta or carrier incidents out of the SLI makes the budget look healthy while customers still waited for OTPs. Count what customers felt; the policy can say that budget spent by an upstream incident triggers resilience work rather than a release freeze.

  • Alerting on raw error rate

    Paging whenever errors exceed 1% for a minute wakes people for blips that cost almost no budget. Page on multi-window burn rate so alerts track the objective, not the noise.

Example

Example: A rough month for an OTP service

A Gurugram lending app sends about 1.2 million authentication templates every 28 days against a 99.5% SLO, so it can afford 6,000 slow or failed sends. On day 9 a 90-minute evening burst of send timeouts burns 22% of the budget. On day 15 a release breaks template parameter mapping for three hours and burns another 37%. A retry-cap misconfiguration then leaks failures for four days, leaving 18%. That crosses the policy's 25% line: feature work stops, the team ships the retry fix and adds a canary stage, and releases resume once the day-9 spike ages out of the rolling window and the budget is back above 25%.

Why it matters

Why does an error budget matter?

Without a budget, reliability debates are opinions: product wants features, operations wants stability, and nobody can say how much risk is acceptable. With one, the trade-off becomes arithmetic. A WhatsApp platform with budget to spare can ship the new bot flow on Tuesday; one that burned 80% of its OTP budget in a bad week pauses that launch and fixes the retry bug first. It also tells the business honestly what a target costs: each extra nine of high availability shrinks the budget tenfold.

Questions

Error Budget FAQs

How do you calculate an error budget?
Subtract the SLO from 100% and apply it to the window. A 99.9% SLO over 30 days allows 0.1% of 43,200 minutes, which is 43.2 minutes; event-based, a 99.5% SLO on 1.2 million sends allows 6,000 bad sends.
What happens when the error budget runs out?
Whatever your error budget policy says, usually a freeze on risky releases. Feature launches pause, engineering time moves to reliability fixes from the incident reviews, and normal releases resume once the budget recovers above the agreed threshold.
What is a good burn rate alert threshold?
A common starting point is the SRE Workbook's set. Page at 14.4x burn over 1 hour or 6x over 6 hours (each checked with a short window too), and open a ticket at 1x over 3 days; tune from there.
Is an error budget the same as an SLA?
No. An SLA is an external contract with penalties such as service credits; an error budget is an internal allowance derived from a stricter SLO. Teams set the SLO tighter than the SLA so the budget runs out before any contract is breached.
Should outages at Meta count against my error budget?
Usually yes, because your customers still felt them. Count them in the SLI, but let the policy treat upstream spend differently, for example by funding queueing or fallback work instead of freezing your own releases.

Notes

Best practices for an error budget

  • Show remaining budget on the same dashboard product managers use to plan releases.
  • Make budget spend part of incident management: every postmortem records how much budget the incident cost and what would have prevented it.
  • Cutting mean time to recovery (MTTR) saves budget directly: an incident fixed in 20 minutes instead of 60 costs a third as much.
  • Unspent budget at the end of a window is a signal you can move faster or that the SLO is looser than customers need.
  • Keep separate budgets for journeys with different stakes, such as OTP sends and marketing broadcasts.

See InfiQ pricing

Put Error Budget to work

InfiQ is an official Meta Business Partner. Start a 7-day free trial — no card needed — and see this running on your own number.

Start free trialBrowse all 550 terms