Module 6: Operating The Claude Code Incident

4. Hands-on: declaring the incident

Description

Module 5, lesson 2 already distinguished detection from declaration: seeing that something is wrong isn't the same as formally saying "this is an incident, and from now on it's handled as one." This lesson writes that message — the formal act of declaration — for the Claude Code incident, following the same pattern Module 5 already established: severity already classified (lesson 3), roles assigned from INCIDENT-RESPONSE-PLAN.md's real list, first known state, and relative timestamps, never a real clock.

Connection to the module

This is this module's first lesson where actual people enter the picture — not just facts and classifications. INCIDENT-RESPONSE-PLAN.md (Module 5) defined the role structure (Incident Commander, Operations Lead, Communications Lead) without assigning it to anyone in particular; oncall/schedule.py's rotation (Module 5, lesson 7) generated eight weeks of real primaries and secondaries, starting March 2, 2026. This lesson does what no previous lesson has done yet: assign those roles to the specific people the real rotation designates, and write the message a real Incident Commander would send in a SEV1's first minute.

Step 1 — A calendar honesty, before assigning roles

Notice a detail worth resolving explicitly, not ignoring: the Claude Code incident happened on February 26, 2026; INCIDENT-RESPONSE-PLAN.md's on-call rotation formally starts on March 2, 2026 — six days later. Literally, schedule.py had no generated week covering February 26.

This lesson resolves that discrepancy with the same honesty this module's lesson 1 already established: this is a deliberate exercise in operating a real incident with Andes Cargo's framework, not a claim that the incident happened within the rotation's real calendar. For this exercise, the incident's date is treated as if it fell within the rotation's Week 1 — the first week schedule.py generated, with Ana as primary and Bruno as secondary — exactly the same kind of explicit design decision lesson 1 already distinguished from a verified fact of the real incident.

Week  Starts      Primary   Secondary
1     2026-03-02  Ana       Bruno          <- week used for this exercise
2     2026-03-09  Bruno     Carla

Step 2 — Assigning the three roles

INCIDENT-RESPONSE-PLAN.md's matrix is explicit about a SEV1's hard rule: "For a SEV1/SEV2, at minimum the IC and OL must be different people". With two people on call that week — Ana (primary) and Bruno (secondary) — the most reasonable distribution is the same one this guide's Module 5, lesson 4, Exercise 2 already resolved for exactly this two-person scenario: one person takes Incident Commander and Communications Lead (both are "full-view" functions, not direct technical execution), and the other takes Operations Lead alone.

Role	Person	Why
Incident Commander (IC)	Ana	Primary on-call that week; coordinates the full response, doesn't execute technical changes
Communications Lead (CL)	Ana (dual role with IC)	Both functions are coordination/communication, not modifying the system — combining them doesn't break `INCIDENT-RESPONSE-PLAN.md`'s central separation
Operations Lead (OL)	Bruno	Secondary on-call that week; the only one who would execute any mitigation action, per Module 5's cited rule: "the only group modifying the system during an incident"

No combination merges IC with OL into the same person — the combination INCIDENT-RESPONSE-PLAN.md explicitly prohibits for a SEV1 — so this assignment respects the hard rule without needing a third person.

Step 3 — The declaration message

A real declaration message, short and structured, serves exactly one function: eliminating any ambiguity about whether the incident "is already official," who's in charge, and what's known as of that moment — nothing more. It's not the place to speculate about root cause (that's Module 7) or to detail the complete mitigation (that's this module's lesson 6).

# INCIDENT DECLARED — SEV1

**Time:** T+~5min (relative to `terraform destroy -auto-approve` execution — see `TIMELINE.md`)
**Declared by:** Ana (Incident Commander)

## Status

Complete infrastructure loss following an unintended `terraform destroy -auto-approve` execution.
VPC, ECS cluster, load balancers, bastion host, and the RDS database (including all automated
snapshots) are gone. `courses_answer` (1,943,200 rows) is affected. No service is currently
reachable.

## Severity

**SEV1** — unrecoverable data loss without external support intervention (Module 6, lesson 3;
matches `INCIDENT-RESPONSE-PLAN.md`'s independent SEV1 criterion, not a burn-rate threshold — no
burn rate is measurable, since no infrastructure remains to generate traffic).

## Roles

- **Incident Commander:** Ana — coordinates the response, owns this document and the timeline,
  does not run mitigation commands directly.
- **Operations Lead:** Bruno — the only person taking mitigation actions during this incident.
- **Communications Lead:** Ana (dual role with IC, per `INCIDENT-RESPONSE-PLAN.md`'s two-person
  guidance for a SEV1/SEV2).

## What we know right now (first known state)

- The destructive command has already run in full — this is not an ongoing degradation, it is a
  completed loss event.
- No self-service recovery path is currently known (see Module 6, lesson 6 for the full
  mitigation decision tree).
- Next update: within 15 minutes, or sooner if status changes materially.

## What this declaration does not claim

Root cause is not analyzed here — that is Module 7's postmortem, built on top of the finished
`TIMELINE.md` this module produces. This declaration exists only to make the incident official,
assign roles, and record the first known state.

Step 4 — Why this declaration works, even though it's short

A real declaration message doesn't need to be exhaustive — it needs to be immediate. Compare it against the real alternative Module 5, lesson 2 already named as the most common error: someone sees the signal, starts investigating on their own, and never formally communicates that the system is in incident mode. Step 3's document avoids that error in under 200 words: it declares the severity immediately (without waiting for a full analysis), assigns the three roles unambiguously, and establishes the first known state without inventing any detail that wasn't yet known for certain — notice that the "What we know right now" section is honest about what's not known yet ("no self-service recovery path is currently known"), instead of projecting a confidence that didn't exist at that moment.

Common mistakes

Writing the declaration after investigating thoroughly, instead of in the earliest possible minute (repeating the error Module 5, lesson 2 already named). What happens: someone, facing a real incident, delays the formal declaration until having a more complete diagnosis, treating declaration as the result of the investigation instead of its starting point. How to spot it: if your declaration includes root-cause details that, in a real incident, wouldn't yet be known in the first minute. How to fix it: Step 3's document declares with the minimum information available at T+~5min — the scale of the damage is already immediately evident (all the infrastructure disappeared), but the "why" isn't investigated here. Declaring fast, with incomplete but honest information, is better than declaring late with complete information.

Merging Incident Commander with Operations Lead into the same person, "because Ana knows how to fix it technically anyway" (breaking Module 5's hard rule under pressure). What happens: someone, when assigning roles for a real SEV1, decides the most technical person should coordinate and execute at the same time, because it seems more efficient in the moment. How to spot it: if your role assignment has the same person signing as IC and also running mitigation commands. How to fix it: INCIDENT-RESPONSE-PLAN.md is explicit — for a SEV1/SEV2, IC and OL must be different people, no exceptions, precisely because mixing deciding with executing under pressure is the same pattern that produced the real Claude Code incident's full blast radius: a single entity with permission to decide and execute at once, with no second person coordinating the decision.

Treating the assignment of Ana and Bruno to Week 1 of the rotation as if it were a verified fact of the real incident, not a design decision of this exercise (repeating the error already named in this module's lesson 1, now with concrete consequences involving people's names). What happens: someone describes the incident saying "Ana was the Incident Commander of the Claude Code incident," as if that were part of DataTalks.Club's real, verified case facts. How to spot it: if your incident summary includes names from Andes Cargo's roster as if they were part of DataTalks.Club's real story. How to fix it: DataTalks.Club, in reality, had no formally assigned Incident Commander or Communications Lead — that's, in fact, part of what this incident reveals about operating without that framework. Ana and Bruno are this exercise's assignment, applying Andes Cargo's rotation to the case, exactly what this lesson's Step 1 made explicit before assigning any name.

Exercises

Exercise 1 — A classmate proposes declaring this incident as SEV2 instead of SEV1, "to avoid unnecessarily alarming the rest of the team with an immediate page." How do you respond, using INCIDENT-RESPONSE-PLAN.md's lesson 3 principle?

See solution

INCIDENT-RESPONSE-PLAN.md quotes, verbatim, PagerDuty's principle already established in Module 5, lesson 3: "when in doubt about which level applies, treat it as the higher one." This case, moreover, has no real doubt that would justify lowering the severity — SEV1's independent criterion (irrecoverable data loss without external intervention) is met unambiguously, per this module's lesson 3 verification. Declaring SEV2 "to avoid alarming" would be exactly the symmetric error Module 5, lesson 3 already named: downplaying a real incident because it feels more comfortable, an error just as costly as its opposite (declaring SEV1 for anything that feels urgent).

Exercise 2 — Rewrite Step 3's "What we know right now" section assuming that, instead of T+~5min, the declaration is written at T+~1h (after the AWS support ticket has already been opened). What would change, and what would stay the same?

See solution

What would change: the section could add that an AWS support ticket (Business Support) has already been opened, and that the team is waiting for confirmation of whether any recoverable snapshot exists — information that didn't yet exist at T+~5min. What would stay the same: the severity (SEV1, unchanged — the criterion that justifies it doesn't depend on elapsed time), the assigned roles (Ana as IC/CL, Bruno as OL — there's no reason to reassign them just because an hour passed), and the honesty of not yet claiming a root cause or a complete mitigation plan — that's still lesson 6 of this module's and Module 7's territory. This exercise demonstrates that the initial declaration doesn't need to be completely rewritten with every update — it gets updated with new facts, on the same structure.

Exercise 3 — Explain why the "What this declaration does not claim" section is a necessary part of the document, and not a simple decorative disclaimer.

See solution

That section exists to prevent a real, common error: someone reading an incident's initial declaration interpreting it as the complete root-cause analysis, instead of as the first known state. Without that explicit section, a hurried reader might assume that "no self-service recovery path is currently known" is a final conclusion, or that the absence of a mentioned root cause means nobody is investigating it. By explicitly declaring what this document does NOT cover — root cause, complete mitigation — the declaration makes its real function clear (making the incident official, assigning roles, fixing the first known state) and precisely points to where the rest of the work lives (this module's lesson 6, and all of Module 7) — the same explicit-boundaries discipline every document in this guide already applies.

Summary and next step

In this lesson you wrote the Claude Code incident's formal declaration message: SEV1, roles assigned from INCIDENT-RESPONSE-PLAN.md's real rotation (Ana as Incident Commander and Communications Lead, Bruno as Operations Lead — respecting the hard rule that IC and OL are never the same person in a SEV1), and the first known state, honest about what wasn't yet known at that moment. You explicitly resolved the calendar discrepancy between the incident's real date (February 26, 2026) and the on-call rotation's formal start (March 2, 2026), treating it as the design decision of this exercise that it is, not as a fact of the real incident.

Before moving on you should be able to: write a declaration message with the same structure for a new scenario; explain why IC and CL can be combined in one person but IC and OL never can; and defend why declaring fast with incomplete information is better than declaring late with complete information.

Lesson 5 shifts angle: what was actually communicated publicly about this incident — with cited sources — versus what should have been communicated internally first, with the cadence a real Communications Lead would maintain over the 24 hours of response.

Resources

This same repository, Module 5, lesson 4 (04-roles-during-an-incident.md) — the definition of the three roles and the hard rule on IC/OL, applied here for the first time with specific people.
This same repository, Module 5, lesson 7 (07-hands-on-a-deterministic-on-call-rotation.md) — oncall/schedule.py, the source of Ana and Bruno as Week 1's primary/secondary.
This same repository, Module 5, lesson 8 (08-project-andes-cargos-incident-response-plan.md) — INCIDENT-RESPONSE-PLAN.md, the exact two-person rule for a SEV1/SEV2.
Google SRE — Incident Management Guide — the declaration phase, already cited in Module 5, lesson 2.

← Previous3. Hands-on: classifying the severity Next →5. Communication during an incident: internal vs. external