Module 5: The Incident Lifecycle
3. Severity levels, with real Andes Cargo examples
Description
A declared incident (lesson 2) still doesn't say how serious it is. "Declared" is binary — yes or no; severity isn't. This lesson installs the vocabulary that answers that second question: four severity levels, SEV1 through SEV4, an industry-wide pattern — this lesson cites PagerDuty's public documentation as a concrete reference — each illustrated with a narrative Andes Cargo example, from the mildest (a shipment that takes two extra seconds) to the most severe (Shipments that stops responding entirely). This module's lesson 5 takes these same four levels and ties them, number for number, to the burn rate thresholds ALERTING-POLICY.md already built — here it's still concept, not arithmetic.
Connection to the module
Without a shared severity vocabulary, two people looking at the same problem can disagree about whether it's worth waking someone up at 3 AM or waiting until Monday — and that disagreement, under real pressure, costs minutes a degrading system doesn't always have. This lesson builds that shared vocabulary; lesson 4 builds who applies it.
The analogy: emergency room triage
In a real emergency room, not every patient who walks in gets the same immediate attention, and that difference isn't arbitrary — a triage nurse evaluates every person who arrives and assigns them a priority, before a doctor ever sees them. A cardiac arrest goes straight to immediate care, no waiting in line. A sprained ankle waits, reasonably, while the cardiac arrest gets treated first. Neither case is "false" or "unnecessary" — they're simply emergencies of a completely different magnitude, and treating them with the same urgency would waste the attention the cardiac arrest desperately needs.
An incident's severity works exactly the same way. Not everything that goes wrong in process-shipment-manifest is a cardiac arrest. Confusing a sprained ankle with a cardiac arrest — treating every minor anomaly as a 3 AM emergency — burns out the on-call team just as fast as confusing a cardiac arrest with a sprained ankle puts the system at real risk. Four levels, from mildest to most severe, exist so that this distinction is made with a shared criterion, not with the individual judgment of whoever happens to be on call that week.
The four levels, cited from real industry practice
Google SRE, the source this guide cites for the lifecycle and the roles, doesn't define numbered severity levels — that's a real omission, not an oversight of this guide (verified directly against the source). The SEV1-SEV4 pattern, instead, is a widely adopted industry convention, publicly documented by PagerDuty in its incident response guide:
SEV-1: "Critical issue that warrants public notification and liaison with executive teams." SEV-3: "Stability or minor customer-impacting issues that require immediate attention from service owners." SEV-4: "Minor issues requiring action, but not affecting customer ability to use the product."
And an explicit principle for what to do in the face of doubt:
"If you are unsure which level an incident is [...] treat it as the higher one."
This guide adapts that pattern — four levels, not five, and without PagerDuty's public-notification requirement, which assumes a company with external paying customers — to Andes Cargo, an internal system with no SLA (RELIABILITY-CHARTER.md, Module 1, already established that). The "when in doubt, the higher severity" principle stays unchanged: correcting a severity downward, with more information, costs far less than correcting it upward after minutes of silence.
SEV4 — Low/cosmetic: noise, not an incident
The lowest level doesn't always even deserve a ticket. Andes Cargo example: shipment 4471's manifest (Peru → Chile) takes two seconds longer than normal to process, due to a brief delay reading the file from andes-cargo-shipment-docs. Full processing finishes in four seconds — well under the ten-second Timeout configured on process-shipment-manifest, with no exception, no retry. Nobody gets notified. If the pattern never repeats, no record remains beyond a routine log line.
SEV3 — Minor: there's a problem, but the system is already handling it
A brief traffic spike momentarily saturates ReservedConcurrentExecutions: 5 — the concurrency limit aws-serverless-and-containers-guide already configured for process-shipment-manifest — and some invocations get delayed while they wait their turn. All of them end up processing correctly after the automatic retry, within seconds. Nobody gets a 3 AM call; someone reviews an automatically generated ticket the next business day, to confirm the pattern isn't becoming more frequent.
SEV2 — Major: a real problem, with visible impact, but no irreversible loss
A deployment with a validation bug causes a real portion of shipment manifests to exhaust their two automatic retries and get silently dropped — the same pattern the BAD_WEEK dataset from Module 2 already modeled with real numbers. Andes Cargo's customers start noticing that their shipment status isn't updating. It's not a total outage — most shipments are still processing fine — but it's serious enough that someone on call addresses it within the same shift, not the next day.
SEV1 — Critical: the system isn't responding, or data is at real risk
Shipments, the DynamoDB table that underpins Andes Cargo's entire tracking system, stops responding entirely. No invocation of process-shipment-manifest manages to write a record — zero shipments get processed, for anyone, until someone steps in. This level 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.
The four levels, at a glance
SEV4 SEV3 SEV2 SEV1
──── ──── ──── ────
2s extra, Throttling Retries exhausted, Shipments not
within the absorbed by real visible responding --
timeout, counts automatic customer impact zero shipments
as a GOOD event retry process
No ticket, Ticket, reviewed Pages on-call, Immediate page,
no page next business responds within Incident Commander
day the same shift assignedCommon mistakes
Assigning SEV1 to anything that feels urgent in the moment (confusing "I'm worried" with "it's critical"). What happens: someone, anxious in the face of any anomaly, declares SEV1 without comparing it against this lesson's concrete examples. How to spot it: if your criterion for SEV1 is "it feels serious," instead of "the system isn't responding at all, or there's irreversible data loss." How to fix it: this module's lesson 5 is going to tie each level to an exact burn rate number, precisely to take "it feels serious" out of the equation — until then, compare against this lesson's four narrative examples: did the system stop responding, or did it just feel uncomfortable to watch it fail a little?
Downplaying a real SEV1 because "it'll probably resolve itself" (the opposite, symmetric error). What happens: someone sees Shipments not responding, but decides to wait a few minutes "to see if it fixes itself," without declaring the incident or notifying anyone. How to spot it: if your response to a completely down system is "let's monitor a bit longer" instead of declaring immediately. How to fix it: this lesson's quote is explicit — when in doubt, the higher severity, never the lower one. A SEV1 that turns out to be milder than it looked gets corrected downward in minutes, at no real cost; a real SEV1 treated as noise for ten minutes of "let's wait and see" can mean ten full minutes of error budget consumed with nobody responding.
Treating the four levels as a continuous scale of "how annoying it is," instead of a discrete threshold criterion (losing the pattern's precision). What happens: someone classifies an incident as "between SEV2 and SEV3," without settling on one or the other. How to spot it: if your severity classification uses words like "sort of" or "almost." How to fix it: this module's lesson 5 exists exactly to eliminate that ambiguity — each level ties to an exact numeric burn rate threshold, with no in-between zone. An incident crosses a threshold or it doesn't; there's no "SEV2.5."
Exercises
Exercise 1 — Classify the following scenario using this lesson's four levels: for one hour, 0.3% of process-shipment-manifest invocations fail with a transient error, retry automatically, and all end up processing correctly. No customer reports any problem.
See solution
SEV3. The scenario has a real, measurable problem (0.3% transient failures) — it isn't as trivial as the SEV4 example (two extra seconds, with no real error ever recorded) — but the system is handling it on its own, with no visible impact to any customer, exactly like this lesson's SEV3 example (throttling absorbed by the automatic retry). There's no signal that it deserves an immediate page to on-call — it does deserve a ticket, to confirm the pattern isn't getting worse.
Exercise 2 — A colleague proposes eliminating SEV3 and SEV4, arguing that "if it's not serious enough to page someone, it's not even worth recording." Using this lesson's PagerDuty quote, explain why that would be a mistake.
See solution
This lesson's own cited definition of SEV-4 is explicit: they're "minor issues requiring action" — the key word is "action," not "no action." Eliminating SEV3 and SEV4 doesn't eliminate those problems; it only eliminates the record that they occurred, which makes any slowly forming pattern invisible (for example, a SEV3 throttling event that happens more and more often, with nobody noticing because it was never recorded). The point of having four levels, not just two, is precisely to capture the low-impact signal without spending the same response effort as a SEV1 — never to ignore it entirely.
Exercise 3 — Explain, using this lesson's SEV1 example, why "the system isn't responding" and "there's irreversible data loss" sit at the same level, instead of two separate ones.
See solution
Both cases share the defining trait of SEV1: once they occur, waiting doesn't improve the situation — every minute that passes without an active response makes the outcome worse (more unprocessed shipments, or data that gets harder and harder to recover), and neither one resolves itself with time. A Shipments that isn't responding at all is, in practice, indistinguishable in urgency from real data loss: in both cases, the correct response is the same (immediate page, Incident Commander assigned, all hands available), even though the exact technical cause differs. Splitting them into two separate levels wouldn't change the response either one needs at all — and a severity level that doesn't change the associated response isn't adding any useful information.
Summary and next step
This lesson installed the four severity levels — SEV1 (critical) through SEV4 (low/cosmetic) — cited from real industry practice (PagerDuty), with one narrative Andes Cargo example per level: from a shipment that takes two extra seconds (SEV4, doesn't even count as a bad event) to Shipments completely down (SEV1, immediate page). The central principle, quoted directly: when in doubt, the higher severity, never the lower one.
Before moving on you should be able to: describe, in one sentence, the difference between each of the four levels; explain why SEV1 covers both "total outage" and "irreversible data loss"; and defend why SEV3 and SEV4 still deserve a record, even though they never warrant a page.
Lesson 4 answers the next question: once an incident has an assigned severity, who responds, and with what specific role? Incident commander, communications, operations — cited, with the same discipline, from Google SRE.
Resources
- PagerDuty — Incident Response: Severity Levels — the cited source for the SEV1-SEV4 levels and the "when in doubt, the higher severity" principle.
- This same repository, Module 4, lesson 8 (
08-project-andes-cargos-alerting-policy.md) —ALERTING-POLICY.md, whose burn rate thresholds this module's lesson 5 ties to these same four levels. - This same repository, Module 1, lesson 8 (
08-project-andes-cargos-reliability-charter.md) —RELIABILITY-CHARTER.md, the decision that Andes Cargo has no external SLA, the reason this lesson doesn't adopt PagerDuty's public-notification requirement.