6. Hands-on: the error budget the Claude Code incident burned

Description

Lesson 5 left a question open, unanswered: what would an error budget have said about the Claude Code incident? This lesson answers it with a real number, calculated by hand, with the same exact arithmetic from the Google SRE book you already cited in lesson 3. It's this whole guide's first executed calculation — not a reusable calculator yet, that arrives in Module 2 — but the complete, deterministic operation, really run with a short Python script you can run yourself and you'll get exactly the same result, always.

Connection to the module

This lesson connects three pieces you already have: the error budget vocabulary from lesson 3 (error budget = 1 − SLO, in minutes over a window), the exact figures from the incident in lesson 5 (24 hours of recovery), and the question lesson 5 left open. This calculation's result — a whole-number multiple of the entire monthly budget, not a small overage — is the number you're going to see again, with the full weight of the formal vocabulary behind it, in this guide's Module 6 (lesson 7 of that module), when you operate this same incident end to end.

Analogy: spending 33 whole prepaid cards on a single purchase

You already know lesson 3's analogy: an error budget is the balance on a prepaid card topped up once a month, with a fixed limit, that doesn't get replenished early. This lesson's result isn't "the card ran out of balance" — it's spending, in a single purchase, the full balance of 33 consecutive monthly prepaid cards, all at once. It's not a minor overage a team could absorb with extra discipline for the rest of the month. It's an event that, measured in this guide's vocabulary, ate more than two and a half years of downtime budget in 24 hours.

Step 1 — The hypothetical SLO, and why it's hypothetical (for now)

Before calculating anything, an important honesty check: DataTalks.Club, in reality, never published a formal SLO before the incident — there's no evidence one existed. This lesson uses a hypothetical, illustrative SLO, not picked at random but chosen with the same criterion lesson 3 of this module already explained: 99.9% monthly, the industry's most common level for a web service that isn't mission-critical — not a real-time payments system, not life support, but also not something with zero availability expectation. This lesson's goal isn't to determine DataTalks.Club's "correct" SLO — that doesn't even make sense for an incident that already happened — it's to demonstrate the complete arithmetic with a reasonable reference number, exactly the same kind of exercise you're going to repeat with Andes Cargo's real SLO in this guide's Module 2, lesson 8.

   SLO = 99.9% monthly
   Window = 30 days = 43,200 minutes

Step 2 — The error budget in minutes, with Google SRE's exact formula

The formula, already cited in lesson 3: error budget = 1 − SLO, applied over the time window in minutes.

   error_budget = (1 − SLO) × window_minutes
   error_budget = (1 − 0.999) × 43,200
   error_budget = 0.001 × 43,200
   error_budget = 43.2 minutes

This is the same number you already saw in lesson 3's nines table: at 99.9% monthly, the whole month's budget is 43.2 minutes of allowed downtime. Less than three quarters of an hour, for an entire month.

Step 3 — The incident's real duration

Grigorev is precise in his own account, quoted verbatim: "Exactly 24 hours after the database had been deleted, AWS restored the snapshot." Twenty-four exact hours, start to finish, until full restoration.

   incident = 24 hours = 24 × 60 = 1,440 minutes

Step 4 — The complete calculation, executed

The following script does exactly this lesson's four steps, in code, with no random value and nothing dependent on the machine's clock — run this script today, tomorrow, or in a year, and the result is always the same, because every input is a fixed data point, not a live measurement.

# error_budget_manual_check.py
# Manual, deterministic calculation: how much error budget the Claude Code incident burned

# --- Step 1: the hypothetical SLO (illustrative, not Andes Cargo's real SLO yet) ---
SLO = 0.999  # 99.9% monthly
WINDOW_DAYS = 30
WINDOW_MINUTES = WINDOW_DAYS * 24 * 60  # minutes in the 30-day window

# --- Step 2: the error budget in minutes ---
error_budget_minutes = (1 - SLO) * WINDOW_MINUTES

# --- Step 3: the incident's real duration (Grigorev: "Exactly 24 hours") ---
INCIDENT_HOURS = 24
incident_minutes = INCIDENT_HOURS * 60

# --- Step 4: how many times the monthly budget was consumed ---
burn_factor = incident_minutes / error_budget_minutes

print(f"Window:                 {WINDOW_DAYS} days = {WINDOW_MINUTES} minutes")
print(f"Hypothetical SLO:       {SLO:.1%}")
print(f"Error budget:           {error_budget_minutes:.1f} minutes")
print(f"Incident:               {INCIDENT_HOURS} hours = {incident_minutes} minutes")
print(f"Budget consumed:        {burn_factor:.1f}x")

What to expect (literal — run this script exactly as it is, with no external dependency, and this is the result, always, with no variation):

Window:                 30 days = 43200 minutes
Hypothetical SLO:       99.9%
Error budget:           43.2 minutes
Incident:               24 hours = 1440 minutes
Budget consumed:        33.3x

The Claude Code incident consumed 33.3 times DataTalks.Club's entire monthly error budget, with a hypothetical SLO of 99.9% — in a single 24-hour event. Not "it went a little over." Not "it was a bad day." An event that, measured with this vocabulary, is equivalent to spending almost three full years' worth (33.3 months) of downtime budget in 24 hours.

Digging deeper: would any reasonable SLO have absorbed this incident?

Worth asking one more question, with the same arithmetic: how lax would DataTalks.Club's SLO have needed to be for 1,440 minutes of downtime to fit inside a single month's budget? It's the same formula, solved backward:

# what SLO makes the full monthly budget >= 1,440 minutes?
break_even_budget_minutes = incident_minutes  # 1440
break_even_slo = 1 - (break_even_budget_minutes / WINDOW_MINUTES)

print(f"Break-even SLO:         {break_even_slo:.4%}")

What to expect (literal):

Break-even SLO:         96.6667%

96.67% is, on lesson 3's nines scale, less than "two nines" — an unusually low service level even for a free, low-budget educational project, the equivalent of treating more than 24 hours of downtime a month, every month, as normal. No SLO any team would pick with real judgment — 99%, 99.9%, not even something as lax as 98% — would have absorbed this incident within a single month without completely exhausting the budget. This isn't a result that's sensitive to which exact SLO would have been chosen: it's an incident that, with almost any reasonable reliability target, eats an entire month's budget and then some.

Second extension: the same calculation, applied to lesson 5's second case

Lesson 4 of this module found that all of andes-cargo-infra/ lives in us-east-1, with no backup region. Lesson 5 named the real outage that region suffered in October 2025: roughly 15 hours of interruption. Worth running exactly the same arithmetic on that number, not because it happened to Andes Cargo — it didn't — but to have, with the same rigor, a concrete sense of what it would represent if it did:

# Extension: if Andes Cargo had been down for the same length of time as
# the real us-east-1 outage (October 2025), how much of its monthly
# budget (same hypothetical 99.9% SLO) would have been consumed?
OUTAGE_HOURS = 15  # real reported duration of the us-east-1 outage, Oct 2025
outage_minutes = OUTAGE_HOURS * 60
outage_burn_factor = outage_minutes / error_budget_minutes

print(f"us-east-1 outage:       {OUTAGE_HOURS} hours = {outage_minutes} minutes")
print(f"Budget consumed:        {outage_burn_factor:.1f}x")

What to expect (literal):

us-east-1 outage:       15 hours = 900 minutes
Budget consumed:        20.8x

An event completely outside Andes Cargo's control — an internal AWS race condition, not a poorly approved destroy — would have consumed, with the same hypothetical SLO, 20.8 times the full monthly budget. Smaller than the Claude Code incident's 33.3x, but just as catastrophic for any reasonable monthly budget. This is, in concrete numbers, why lesson 5 insisted both cases demand the same measurement discipline — SLI, SLO, error budget, postmortem — even though their root causes have nothing in common: an error budget doesn't ask an incident why it happened before counting what it cost.

Common mistakes

Confusing this lesson's hypothetical SLO with Andes Cargo's real SLO (jumping ahead). What happens: someone assumes 99.9% monthly is "Andes Cargo's official SLO," and cites it as such in a later lesson. How to spot it: if you mention "Andes Cargo's SLO" before reaching this guide's Module 2, lesson 8. How to fix it: this lesson's 99.9% is exclusively a reference value to demonstrate the arithmetic over a real incident that already happened, chosen because it's the industry's most common level for a service like DataTalks.Club — not a decision made for Andes Cargo. Andes Cargo's real SLO gets chosen, with its own business justification, in Module 2.

Rounding the result to "it went over budget" without retaining the exact magnitude (loss of precision). What happens: someone remembers "the incident exceeded the error budget" but doesn't retain the specific multiple — 33.3x — and treats it like any overage, comparable to an incident that consumes, say, 1.2 times the budget. How to spot it: if your description of the incident doesn't include the number "33.3x" or its equivalent in months (33.3 months of budget in one day). How to fix it: the exact magnitude is this lesson's central pedagogical point — an error budget exceeded by 1.2x suggests a different response (review the process, adjust the SLO) than one exceeded by 33.3x (a catastrophic, systemic failure, not normal variation). The exact number, not the category "it went over," is what an error budget contributes that a qualitative description doesn't.

Thinking this calculation is already this guide's "error budget calculator" (scope jump). What happens: someone, after running this lesson's script, assumes they already have the full tool Module 2 promises to build, and wonders what's missing. How to spot it: if you expect this script to handle real traffic datasets, multiple configurable SLOs, or multi-window burn rate calculation. How to fix it: this is, deliberately, a manual calculation for a single case — one input, one result, no reuse. scripts/error_budget_calculator.py, Module 2's real deliverable, generalizes this exact same formula so it accepts any SLO, any window, and any traffic dataset, and extends it with burn rate in Module 4. This lesson built the formula by hand, once, so you understand exactly what that tool automates before you use it.

Exercises

Exercise 1 — Recalculate the factor with a different SLO, without running the script. If the hypothetical SLO had been 99% monthly (instead of 99.9%), how many minutes of budget would there be, and how many times would the same 1,440-minute incident have consumed it? Do the math by hand.

Exercise 2 — Explain, in your own words, why the break-even SLO (96.67%) is a revealing figure, not just a curious number. What does that number tell you about the incident's real severity, compared to simply knowing "it lasted 24 hours"?

Exercise 3 — Modify the script to express the result in "months of budget" instead of a unitless factor. Without running anything yet, write the line of code you'd add to this lesson's script to explicitly print "this incident consumed X full months' worth of budget," using the variables already defined.

print(f"In months of budget: this incident equals {burn_factor:.1f} months of allowed downtime, consumed in a single day.")

Summary and next step

In this lesson you did this whole guide's first real calculation: with a hypothetical monthly SLO of 99.9% (43.2 minutes of budget), the 24 hours (1,440 minutes) it took to recover from the Claude Code incident consumed 33.3 times the entire monthly error budget — not a minor overage, but the equivalent of spending almost three years' worth of budget in a single day. You confirmed, with a second extension of the same calculation, that no reasonable SLO — only one as lax as 96.67%, below any serious industry standard — would have absorbed this incident within a single month.

Before moving on you should be able to: run this lesson's script and get exactly 33.3x; explain why this lesson's SLO is hypothetical, not Andes Cargo's real SLO; and calculate by hand, without the script, the consumption factor for an SLO other than this lesson's.

Lesson 7 formalizes all the vocabulary you've already used in this module — SLI, SLO, SLA, error budget, toil, on-call, postmortem — in a short glossary, quoted from the official Google SRE source.

Resources

1. Alexey Grigorev — How I Dropped Our Production Database — the primary source for "Exactly 24 hours after the database had been deleted, AWS restored the snapshot," this lesson's central data point.
2. Google SRE Workbook — Implementing SLOs — the exact error budget formula (1 − SLO) this lesson applies.
3. Google SRE Book, Chapter 3 — Embracing Risk — the error budget's conceptual framework, already cited in lesson 3 of this module.