Module 6: Operating The Claude Code Incident
7. This incident's error budget, with the full vocabulary
Description
This guide's Module 1, lesson 6 made the whole guide's first real calculation: with a hypothetical 99.9% monthly SLO, the 24 hours of recovery consumed 33.3 times the full monthly budget — a one-off script, error_budget_manual_check.py, written before any reusable tool existed. This lesson repeats that calculation, with two differences that completely change its weight: instead of a one-off script, it uses scripts/error_budget_calculator.py's real functions (Module 2, lesson 4); and instead of a hypothetical SLO chosen only to illustrate the arithmetic, it uses Andes Cargo's real SLO, the one SLO.md set with evidence in Module 2 — which, by a coincidence worth examining, is exactly the same number.
Connection to the module
This is this module's last technical lesson before the final project (lesson 8). It brings together, in one place, every piece of vocabulary this guide has built since Module 1: SLI, SLO, error budget, burn rate — with the distinction, already established in this module's lesson 3, between what can be calculated with real data (error budget in minutes) and what can't be calculated at all for this specific incident (burn rate, because there's no observable error rate when no system remains to generate traffic).
Step 1 — Why this time the SLO isn't hypothetical
Module 1, lesson 6 was explicit about an honest limitation: the 99.9% SLO it used was "hypothetical and illustrative," chosen because it's the industry's most common level for a service like DataTalks.Club, not because it was "the correct SLO" for anyone in particular — DataTalks.Club, in reality, never published a formal SLO. This lesson has something that lesson still didn't: SLO.md, Andes Cargo's real document (Module 2, lesson 8), with an SLO chosen after running the calculator three times against real data, not chosen for being "the industry's most common."
SLO.md's result: 99.9% monthly — the exact same number Module 1 used as an illustration. This isn't a coincidence forced by this design — it's confirmation, with real evidence measured in Module 2, that Module 1's illustrative choice turned out to be reasonable: 99.9% is, in fact, the level a system comparable to process-shipment-manifest can sustain with real data, without being so lax it stops meaning anything (the problem SLO.md ruled out with 99%) nor so strict the system constantly misses it (the problem SLO.md ruled out with 99.99%). This lesson can, with complete honesty, stop saying "hypothetical" — the number now has SLO.md's full evidence behind it.
Step 2 — Reusing the real function, not a new script
error_budget_calculator.py (Module 2, lesson 4) already has the exact function this lesson needs: error_budget_minutes(slo, window_minutes), which implements Google SRE's formula, (1 - SLO) × window minutes. This lesson doesn't rewrite that function — it reuses it, exactly as is, with SLO.md's real values and the incident's real duration:
# incident_error_budget_with_calculator.py
# Reuses error_budget_minutes() from scripts/error_budget_calculator.py (Module 2, lesson 4)
# -- same function, same formula -- now applied to the real incident with SLO.md's real SLO
# (Module 2, lesson 8), not a hypothetical SLO like in Module 1, lesson 6.
def error_budget_minutes(slo, window_minutes):
"""error budget = (1 - SLO) x minutes of the window the SLO promises.
Identical to the function in scripts/error_budget_calculator.py -- Module 2, lesson 4."""
return (1 - slo) * window_minutes
# --- SLO.md's real SLO (Module 2, lesson 8) -- not hypothetical ---
SLO = 0.999 # 99.9% monthly, SLO.md
SLO_WINDOW_MINUTES = 30 * 24 * 60 # 43,200 minutes, the window SLO.md promises
# --- The incident's real duration, verified against the primary source ---
# Grigorev: "Exactly 24 hours after the database had been deleted, AWS restored the snapshot."
INCIDENT_MINUTES = 24 * 60 # 1,440 minutes
# --- The complete calculation, with budget_report()'s formal vocabulary ---
budget_minutes = error_budget_minutes(SLO, SLO_WINDOW_MINUTES)
minutes_consumed = INCIDENT_MINUTES # the full 24 hours, counted as budget consumed
minutes_remaining = budget_minutes - minutes_consumed
consumed_pct = (minutes_consumed / budget_minutes) * 100
burn_factor = minutes_consumed / budget_minutes
print(f"SLO (SLO.md): {SLO:.1%}")
print(f"Error budget: {budget_minutes:.1f} minutes")
print(f"Incident duration: {INCIDENT_MINUTES} minutes (24 hours)")
print(f"Consumed: {minutes_consumed} minutes ({consumed_pct:.1f}% of budget)")
print(f"Remaining: {minutes_remaining:.1f} minutes")
print(f"Burn factor: {burn_factor:.1f}x the full monthly budget")What to expect (literal — run this script exactly as is, and this is the result, always, without variation):
SLO (SLO.md): 99.9%
Error budget: 43.2 minutes
Incident duration: 1440 minutes (24 hours)
Consumed: 1440 minutes (3333.3% of budget)
Remaining: -1396.8 minutes
Burn factor: 33.3x the full monthly budget
Step 3 — The same result, with more information than Module 1 ever calculated
33.3x — the exact same number Module 1, lesson 6 got with its one-off script. That's not surprising: the formula is identical, the SLO is the same number (99.9%), and the incident duration is the same verified figure (24 hours). What this lesson has, that Module 1 never calculated, are two additional figures error_budget_calculator.py's budget_report() knows how to produce and that one-off script didn't include: budget consumed as a percentage (3,333.3%) and remaining budget (-1,396.8 minutes).
The negative remaining budget is the most honest of the three figures. A remaining budget of -1,396.8 minutes doesn't mean "negative budget" in the sense of a debt paid off later with interest — the error budget doesn't work that way, as SLO.md and Module 2 already established. It means, with arithmetic precision: if this SLO's thirty-day cycle had to absorb, within itself, both the original budget (43.2 minutes) and the additional deficit this incident generated (1,396.8 more minutes), the month would need almost 33 times its normal length just for the balance to return to zero. It's the same idea Module 1 already communicated with "33.3 months of budget in a single day" — but now expressed with budget_report()'s complete formal vocabulary, the same format any real run of the calculator over Andes Cargo's normal traffic (Module 2, lesson 4) already produced.
Step 4 — Why this lesson doesn't calculate burn rate, again
It would be tempting, in this lesson, to extend Step 2's script with Module 4's burn rate formula — burn_rate = observed_error_rate / allowed_error_rate — to "complete the vocabulary." This module's lesson 3 already explained, precisely, why that's not possible here: burn rate needs an observed error rate, measured against real traffic still arriving at a system that still exists. This incident doesn't have that — from T+0 on, there was no system to send traffic to, and therefore no error rate to calculate.
The error budget in minutes, in contrast, can be calculated, because it doesn't depend on an observed traffic rate — it only depends on the duration of the outage, a figure that does exist precisely (24 hours, verified by the primary source). This is the real reason, with the full vocabulary in plain sight, why this guide uses two different tools for two different questions: error_budget_calculator.py measures the cost of a known outage, with no live traffic needed; burn_rate_evaluator.py (Module 4) measures the consumption speed of a system still receiving traffic, while it receives it. The Claude Code incident is, precisely, a case where only the first tool applies — and it's exactly the same reason, with the same vocabulary, that this module's lesson 3 classified the severity with the independent data-loss criterion, not a burn rate threshold.
TWO TOOLS, TWO QUESTIONS -- WHY ONLY ONE APPLIES HERE
error_budget_calculator.py burn_rate_evaluator.py
(Module 2) (Module 4)
────────────────────────── ─────────────────────
Question: "how much did an Question: "how fast is
outage of known duration the budget being consumed
cost, in minutes of RIGHT NOW, with traffic
budget?" still arriving?"
│ │
▼ ▼
Only needs: the outage's Needs: real, live
duration traffic, being measured
│ │
▼ ▼
DOES APPLY to the Claude DOES NOT APPLY to the
Code incident -- the duration Claude Code incident --
(24 hours) is a real, there's no traffic to
verified figure measure from T+0 onwardCommon mistakes
Treating this lesson's "33.3x" as a different or more authoritative number than Module 1's "33.3x," instead of recognizing it as the same result with more context (overvaluing the repetition). What happens: someone presents this lesson's calculation as if it corrected or improved Module 1's result, without noticing the number is identical. How to spot it: if your explanation of this lesson includes the phrase "the real number is different from Module 1's." How to fix it: this lesson's Step 3 was explicit — the number is exactly the same, 33.3x, because the formula, the SLO (99.9% in both cases), and the incident duration (24 hours, verified) are identical between both lessons. What changes isn't the result — it's the SLO's source (hypothetical in Module 1, real and evidence-backed in SLO.md here) and the tool that calculates it (a one-off script versus error_budget_calculator.py's reusable function).
Trying to "complete" the vocabulary by adding an invented burn rate calculation, instead of accepting that piece of vocabulary doesn't apply to this incident (forcing a formula where it doesn't fit). What happens: someone, uncomfortable that the lesson doesn't calculate burn rate, invents an arbitrary error rate (for example, assuming "100% errors" over the 24 hours) to be able to complete the calculation. How to spot it: if your version of this lesson includes a burn rate number not backed by any real, verified traffic rate. How to fix it: this lesson's Step 4, and this module's lesson 3 before it, already established why inventing an error rate here would be mathematically incorrect — there's no real traffic to measure from T+0 on. The absence of a burn rate calculation isn't a gap in this lesson's vocabulary — it's the correct, honest application of a tool that, by design, doesn't work for this specific case.
Confusing "remaining budget: -1,396.8 minutes" with a real debt that Andes Cargo or DataTalks.Club "owes" in some financial or contractual sense (taking the budget analogy too literally). What happens: someone interprets the negative number as if it implied some real contractual or financial consequence, similar to a breached SLA with penalties. How to spot it: if your explanation of the negative remaining budget mentions something that "has to be paid" or "made up for" to someone external. How to fix it: this guide's Module 1, lesson 7 already precisely distinguished an SLO (internal engineering target) from an SLA (external contract with real consequences) — Andes Cargo, per RELIABILITY-CHARTER.md, has no SLA. The negative number is a measure of how much the internal target was missed by, useful for deciding how much urgency preventing a repeat deserves — never a real financial or contractual obligation.
Exercises
Exercise 1 — Modify, in prose (without running anything), Step 2's script to calculate how many "full months of budget" the -1,396.8-minute deficit represents, using only the variables already defined.
See solution
Since budget_minutes (43.2) already represents one full month of budget, dividing the deficit's absolute value by budget_minutes gives the answer directly: deficit_in_months = abs(minutes_remaining) / budget_minutes. With this lesson's values: 1396.8 / 43.2 = 32.3 additional months of deficit, beyond the one month already fully consumed — one more way of expressing the same magnitude burn_factor (33.3x) already communicates, but focused specifically on how far below zero the balance fell, not on how many times the original total was consumed.
Exercise 2 — Explain, using Step 4, why this module's lesson 3 SEV1 classification and this lesson's inability to calculate burn rate are, at bottom, the same observation applied twice.
See solution
Both observations stem from the same technical fact: from T+0 on, no system exists generating measurable traffic. This module's lesson 3 used that fact to explain why severity couldn't be classified with the matrix's numeric burn rate threshold — it had to resort to the independent data-loss criterion. This lesson uses the same fact to explain why burn_rate_evaluator.py doesn't apply to this incident, while error_budget_calculator.py does, because the latter doesn't depend on live traffic. It's the same technical root cause — total absence of infrastructure, and therefore of telemetry — seen from two different angles of this guide's vocabulary: severity in lesson 3, calculation tool in this lesson.
Exercise 3 — A technical interviewer asks: "why reuse error_budget_minutes() from error_budget_calculator.py instead of just re-running Module 1's script?" Answer using this lesson's Step 2.
See solution
A complete answer: "Module 1's script was, deliberately, a one-off manual calculation, built before any reusable tool existed in this guide — its own summary says so explicitly. Reusing error_budget_calculator.py's real function demonstrates something the original script couldn't demonstrate on its own: that the same tool Andes Cargo uses to measure its normal traffic (Module 2), its synthetic bad week (also Module 2), and that it's going to use in Module 8 against a new incident, produces exactly the same mathematical result when given the duration of a real incident that already happened. It's not just a matter of not repeating code — it's proof that the calculator generalizes correctly, with no special adjustment needed, to the specific case of a historical incident."
Summary and next step
This lesson recalculated the Claude Code incident's error budget, reusing error_budget_calculator.py's (Module 2, lesson 4) error_budget_minutes() instead of Module 1's one-off script, and using SLO.md's real SLO (99.9%, with complete evidence) instead of a hypothetical value. The result — 33.3x the full monthly budget — is identical to Module 1's, confirming that lesson's illustrative choice turned out to be reasonable. You added two new figures the original calculation never produced (3,333.3% consumed, -1,396.8 minutes of remaining budget), and confirmed, with the complete SLI/SLO/error budget/burn rate vocabulary, why this lesson calculates error budget but deliberately doesn't calculate burn rate for this specific incident.
Before moving on you should be able to: run this lesson's script and get exactly the same numbers; explain why the result is identical to Module 1's despite using a different source for the SLO; and defend why burn rate doesn't apply to this incident while error budget does.
Lesson 8, this module's final project, integrates everything lessons 2 through 7 built — timeline, severity, roles, decision tree, error budget — into the final, complete version of TIMELINE.md, the portfolio piece Module 7 is going to cite directly in the blameless postmortem.
Resources
- This same repository, Module 1, lesson 6 (
06-hands-on-the-error-budget-the-claude-code-incident-burned.md) — the original calculation, with a hypothetical SLO, that this lesson recalculates with the real tool. - This same repository, Module 2, lesson 4 (
04-hands-on-the-error-budget-calculator.md) —error_budget_calculator.py, the source of theerror_budget_minutes()function reused here. - This same repository, Module 2, lesson 8 (
08-project-andes-cargos-slo-md.md) —SLO.md, the source of the real SLO (99.9%) used in this lesson. - Google SRE Workbook — Implementing SLOs — the exact error budget formula applied in this lesson.