Module 6: Operating The Claude Code Incident
3. Hands-on: classifying the severity
Description
TIMELINE.md already exists. The next question a real team asks itself, in the first minutes of any incident, is the one Module 5 already prepared to answer with arithmetic, not instinct: how serious is this? This lesson applies INCIDENT-RESPONSE-PLAN.md's exact severity matrix to the Claude Code incident, and arrives at a verdict that admits no ambiguity — SEV1 — for a reason worth understanding precisely, because it isn't the most obvious one.
Connection to the module
INCIDENT-RESPONSE-PLAN.md's severity matrix (Module 5, lesson 5) ties each level to an exact burn rate threshold: SEV1 at Page (fast), ≥ 14.4x. This lesson's temptation would be to calculate the Claude Code incident's burn rate and confirm it crosses that threshold. This lesson does something different, and more honest: it shows why that calculation, for this specific incident, cannot be done — and why the severity matrix itself already anticipated exactly this case with an independent criterion, quoted verbatim in Module 5's lesson 5.
Step 1 — The attempt to calculate burn rate, and why it fails
Before applying the correct criterion, it's worth attempting the obvious calculation, to understand precisely why it doesn't work here. ALERTING-POLICY.md's and the severity matrix's formula:
burn_rate = observed_error_rate / allowed_error_rateCalculating an observed error rate requires a numerator and a denominator: failed invocations, over total invocations, measured by an observability system that's receiving and processing that data in real time — exactly what process-shipment-manifest and the CloudWatch/Prometheus pipeline from this guide's Modules 3 and 4 do for Andes Cargo. The problem, in the Claude Code incident: from T+0 on, there's no running system that could generate those invocations, and no metrics pipeline that could record them. The VPC, the ECS cluster, the load balancers — all the infrastructure, including any piece of observability that had existed — were destroyed in the same command.
WHY THE BURN RATE CALCULATION DOES NOT APPLY HERE
A system with partial The Claude Code incident
degradation (the typical (total infrastructure destruction)
case ALERTING-POLICY.md
measures)
Traffic KEEPS arriving -- There IS NO traffic -- no
some fails, some succeeds, server to receive a request,
both get measured no metrics pipeline to record it
│ │
▼ ▼
burn_rate = observed rate / burn_rate = 0/0 --
allowed rate -- a real, undefined. It's not "100%
calculable number errors," it's the TOTAL
ABSENCE of any measurementIt's not that the observed error rate is 100% — that would, in fact, be the most common interpretation, and the incorrect one. A 100% error rate still implies invocations are happening, all of them failing. Here there are no invocations at all: there's no system to invoke. The burn rate formula breaks mathematically (0 / 0, undefined), not because the result is extreme, but because both of its inputs stopped existing.
Step 2 — The criterion that does apply, already anticipated by INCIDENT-RESPONSE-PLAN.md
This guide's Module 5, lesson 5 — while building the severity matrix, long before this module existed — already settled this, with a precision worth rereading:
"[SEV1] isn't reserved only for 'the system is down': it also covers irreversible data loss without external support intervention, even if the system is technically still responding to other requests — the exact, deliberate distinction this guide's Module 6 is going to apply when classifying the real Claude Code incident."
And that same lesson's "Common mistakes" section, written before this module was written, anticipated exactly Step 1's problem:
"A scenario like the Claude Code incident, where the entire infrastructure was destroyed, might generate no measurable burn rate at all (there are no failing invocations if there's no infrastructure to invoke) — that's why this matrix includes irreversible data loss as an independent SEV1 criterion, one that doesn't wait for any number to cross any threshold."
The SEV1 row in INCIDENT-RESPONSE-PLAN.md is written, literally, with an "OR" operator: Page (fast), >= 14.4x — OR unrecoverable data loss, regardless of measured burn rate. The Claude Code incident doesn't cross the burn rate threshold because there's no number to calculate — it crosses the second criterion, irrecoverable data loss, directly and unambiguously.
Step 3 — Verifying the criterion, fact by fact
Before declaring SEV1, it's worth confirming the incident precisely meets the exact definition of "irrecoverable data loss without external support intervention" — it's not enough that it "feels serious":
| Matrix criterion | Met? | Evidence from TIMELINE.md |
|---|---|---|
| Was there real data loss? | Yes | courses_answer, 1,943,200 rows, destroyed at T+0 along with every automated snapshot |
| Was it recoverable with the team's own tools, without outside help? | No | The team itself had no snapshot accessible from its own console — this module's lesson 6 details why |
| Did it require external support intervention (outside the team's direct control)? | Yes | Escalation to AWS Business Support, a snapshot visible only on AWS's internal side, not the customer's |
| Was the system, technically, still responding to other requests during this time? | Not applicable here, but the matrix criterion is explicit that it doesn't matter | The entire infrastructure was destroyed — a case even more severe than the minimum scenario the matrix contemplates for SEV1 |
All four rows confirm, unambiguously, SEV1's independent criterion: real data loss, unrecoverable with the team's own means, requiring external intervention. The Claude Code incident doesn't just meet this criterion's minimum bar — it exceeds it: it's not a borderline case where the system kept responding but the data was at risk, it's the most severe possible case within the same category, where absolutely nothing kept working.
Step 4 — Verdict
SEV1. Not from a burn rate calculation — which, as Step 1 demonstrated, can't even be performed here — but from the explicit, independent criterion INCIDENT-RESPONSE-PLAN.md already included, precisely, for exactly this kind of case: irrecoverable data loss without external support intervention. The response that level demands, per the same table: "Page on-call immediately. Incident Commander assigned. All hands as needed." This module's lesson 4 assigns, with a specific name and role, who responds to that page.
Common mistakes
Trying to force a burn rate number anyway, assuming "100% errors" is mathematically the same as "no data" (confusing two different scenarios). What happens: someone calculates the Claude Code incident's burn rate assuming a 100% error rate, getting a result (1,000x, the same number Module 5, lesson 5's Step 2 already calculated for the hypothetical Shipments-not-responding scenario) without noticing that number doesn't apply here. How to spot it: if your SEV1 justification for this incident includes a calculated burn rate number. How to fix it: this lesson's Step 1 is explicit — a 100% error rate still requires invocations to exist that fail; the Claude Code incident has no possible invocation at all, because there's no system to invoke. They're two different scenarios, even though both end in SEV1: one crosses the numeric burn rate threshold, the other crosses the independent data loss criterion.
Assuming that, without a calculable burn rate number, the severity classification becomes subjective or debatable (losing sight of how rigorous the independent criterion still is). What happens: someone concludes that, since this incident "has no exact number behind it," the SEV1 classification depends on whoever's evaluating it personal judgment. How to spot it: if your argument for SEV1 uses phrases like "it was obviously serious" instead of citing the matrix's explicit criterion. How to fix it: this lesson's Step 3 verified, fact by fact against TIMELINE.md, every condition of SEV1's independent criterion — real data loss, unrecoverable with the team's own means, requiring outside intervention. The criterion is just as rigorous and verifiable as any numeric threshold; it simply doesn't depend on an arithmetic formula.
Concluding, upon seeing the burn rate criterion doesn't apply, that ALERTING-POLICY.md (Module 4) has a design gap (misreading a known limitation as a bug). What happens: someone argues that Andes Cargo's burn rate alert "wouldn't have detected" an incident like this, and presents it as a flaw in the alerting system. How to spot it: if your conclusion from this lesson is "we need to redesign ALERTING-POLICY.md to cover this case." How to fix it: no metrics-based alerting system can detect the total absence of the infrastructure that reports those metrics — it's a physical limitation, not a fixable design flaw. The reason INCIDENT-RESPONSE-PLAN.md includes the independent data loss criterion, instead of depending on burn rate alone, is precisely to cover this kind of case where no metrics system can alert on its own nonexistence.
Exercises
Exercise 1 — A colleague proposes that, since Andes Cargo's system can't calculate burn_rate when the entire infrastructure disappears, it should automatically be declared SEV1 "for absence of data," even when the absence is due to planned maintenance. Do you agree?
See solution
Disagree. The real SEV1 criterion in INCIDENT-RESPONSE-PLAN.md isn't "absence of burn rate data" — it's "irrecoverable data loss without external support intervention." Planned maintenance could also leave a window with no burn rate data, but it implies no real data loss, and needs no emergency external intervention — it's a known, controlled, reversible-by-design condition. Confusing "there's no burn rate number available" with "this is automatically SEV1" would ignore exactly the distinction this lesson established: the independent criterion demands real data loss, not merely the inability to calculate a formula.
Exercise 2 — Explain, using this lesson's Step 1, why burn_rate = 0/0 is a more precise description of the Claude Code incident than burn_rate = infinite.
See solution
burn_rate = infinite would imply the numerator (the observed error rate) grows without bound while the denominator stays fixed — a description that would incorrectly suggest something is indeed being measured, just at an extreme level. burn_rate = 0/0 is the mathematically correct description: both the numerator and the denominator — failed invocations and total invocations — are zero, because there's no system generating any invocation at all. The distinction isn't a technicality: 0/0 correctly communicates that the problem is the total absence of measurement, not an extreme measurement, exactly this lesson's Step 1 central point.
Exercise 3 — Compare this incident's severity to INCIDENT-RESPONSE-PLAN.md's narrative SEV1 example (Shipments stops responding entirely, 1,000x burn rate). Is the Claude Code incident "just as serious," "less serious," or "more serious" than that example? Justify with this lesson's Step 3.
See solution
More serious, and the lesson's own table confirms it in its last row. The narrative Shipments-not-responding example is a case of total unavailability, but without data loss — once Shipments responds again, the data is still there, intact, waiting for the next successful invocation. The Claude Code incident combines total unavailability (nothing was responding) with real data loss (courses_answer and everything else, destroyed, with no snapshot accessible on the customer side). Both cases are SEV1, because both cross that category's minimum threshold, but the Claude Code incident does it twice over — total unavailability and real data loss — while INCIDENT-RESPONSE-PLAN.md's narrative example only crosses the first condition. The severity matrix has no "SEV0" level to distinguish this difference; both cases get the same maximum response, exactly as Module 5, lesson 3 already explained about why both criteria share the same level.
Summary and next step
This lesson classified the Claude Code incident as SEV1, verified with INCIDENT-RESPONSE-PLAN.md's exact criterion — not from a burn rate calculation, which this lesson demonstrated turns out mathematically undefined (0/0) when the entire infrastructure disappears, but from the independent criterion of irrecoverable data loss without external support intervention, already precisely anticipated in Module 5, lesson 5. You confirmed, fact by fact against the previous lesson's TIMELINE.md, every condition of that criterion: real loss, unrecoverable with the team's own means, requiring escalation to AWS.
Before moving on you should be able to: explain why this incident's burn rate can't be calculated; cite INCIDENT-RESPONSE-PLAN.md's independent SEV1 criterion; and compare this incident's severity to the narrative Shipments-not-responding example.
Lesson 4 takes this classification and produces the next operational document: the formal declaration message, with INCIDENT-RESPONSE-PLAN.md's roles assigned to specific people from the on-call rotation.
Resources
- This same repository, Module 5, lesson 5 (
05-hands-on-andes-cargos-severity-matrix.md) — the complete matrix and SEV1's independent criterion, quoted verbatim in this lesson. - This same repository, Module 5, lesson 8 (
08-project-andes-cargos-incident-response-plan.md) —INCIDENT-RESPONSE-PLAN.md, the source of the SEV1 row applied here. - Google SRE Workbook — Alerting on SLOs — the burn rate formula whose limit this lesson demonstrates with a real case.
- Alexey Grigorev — How I Dropped Our Production Database — the source of the facts verified in Step 3.