Incident Postmortem

Team·Winter·2% of the winter grade

• Incident PostmortemSunday of week 9·Rubric

Winter’s retrospective, in the form of one analyzed failure.

Up to 48 hours late loses one rubric band on each criterion. After that it scores zero, unless you contacted the instructors before the deadline with a documented reason.

By week 9 of winter, something real has gone wrong: an outage, a bad merge that cost a weekend, a dependency or platform surprise, a security scare, a missed commitment, a partner miscommunication that burned a sprint. Pick the most instructive one and write the document engineering teams write when it happens to them: a blameless postmortem.

Blameless means the unit of analysis is the system, not the person. “Alex broke the deploy” is banned; “the deploy process allowed an untested migration to reach production because nothing checked for it” is the genre. The test of blamelessness: every person involved would happily co-sign the document. Google’s SRE book chapter on postmortem culture is the reference text for the practice, and the Retrospectives guide covers what a blameless postmortem costs when it is not. Write to the six sections below, which are what the rubric checks: the guide’s five-area sketch is the industry shape, not this assignment’s.

If nothing went wrong

Some terms really are quiet. If your team cannot name an incident, write the postmortem on a near miss: something that would have caused real damage and did not, because a test failed, a review comment landed, someone noticed in time, or you got lucky. Near-miss analysis is standard practice in aviation, medicine and industrial safety, where waiting for real incidents is too expensive to be a learning strategy. The document is identical except that the impact section becomes what the impact would have been and how close it came.

If you can’t name a near miss either, that’s your finding, and it’s a real one: nothing in your process is currently surfacing problems early enough to see them. Write that up instead, using the same structure, with the timeline tracing how a plausible failure would travel through your system undetected and the corrective actions aimed at detection. Tell your Teaching Assistant (TA) in week 7 rather than week 9, so there’s time to scope it properly.

What You Produce

The postmortem is two to three pages.

Where the incident is technical, keep the postmortem with the work, in the repository: an issue, an ADR, or the PR that fixes it. Otherwise keep it with your team’s documents.

1. Summary and impact: what happened, when, who and what was affected, in factual, measurable terms.
2. Timeline: the sequence of events, decisions, and signals (including missed ones), timestamped where possible.
3. Root cause analysis: why it happened, past the first answer (five whys or contributing-factors style). Include what made detection slow, if it was.
4. What went well: what limited the damage; credit where it’s due.
5. Corrective actions: 3 to 5 specific changes with owners and dates, distinguishing “prevent recurrence” from “detect faster”. At least one must be verifiable at the week-10 repo checkpoint or in the week-10 sprint note.
6. AI involvement, if any: if AI-generated code or advice contributed to the incident or to the recovery, say so plainly; both are normal and instructive.

Start from the postmortem template.

AI use: AI may reconstruct the timeline from logs, commits, and chat history, and draft the write-up. It must not invent events or timestamps, or supply a tidier root cause than the evidence supports. A fabricated timeline, or a corrective action with no real owner, fails the assignment. Section 6 asks you to say when AI contributed to the incident; the same disclosure applies to the document.

What You Submit

The postmortem as one PDF, with the cover Submitting Your Work describes.

Rubric

Rubric: 100 points across 5 criteria

Criterion	Ratings
Impact and timeline: statement, sequence, missed signals25 pointsOutcomes: SO3	Exceeds Expectations (25)States what happened, when, and who or what was affected; sequences events, decisions, and signals with the times the record has; names at least one missed signal or says there was none. Meets Expectations (20)One of the three missing. Does Not Meet Expectations (5)Two or more of the three missing.
Root cause analysis: past the first answer, detection included25 pointsOutcomes: SO6	Exceeds Expectations (25)Analysis goes past the first answer to a condition the team can change, such as a missing check or an unclear handoff (five-whys or contributing-factors style), and includes what made detection slow, if it was. Meets Expectations (20)Analysis goes one level deep but stops early, misses contributing factors, or does not examine detection. Does Not Meet Expectations (5)Analysis stops at the first answer or lands on a scapegoat.
Blameless throughout15 pointsOutcomes: SO4	Exceeds Expectations (15)Every cause is stated as what a process, check, or tool allowed, or as an event outside the team's control, and no sentence names a person as a cause, so every person involved could co-sign the document. Meets Expectations (12)One or two sentences name a person as a cause. Does Not Meet Expectations (3)Three or more sentences name a person as a cause.
Corrective actions: 3 to 5, owned, dated, verifiable25 pointsOutcomes: SO2	Exceeds Expectations (25)3 to 5 changes, none a resolution like "be more careful", each with an owner and a date, distinguishing "prevent recurrence" from "detect faster"; at least one is verifiable at the week-10 repo checkpoint or in the week-10 sprint note. If AI contributed to the incident or the recovery, the document says so. Meets Expectations (20)Actions are listed, but there are fewer than 3 or more than 5, some lack owners or dates, the prevent/detect distinction is missing, none is verifiable at the week-10 checkpoint or sprint note, or AI contributed to the incident or the recovery and the document does not say so. Does Not Meet Expectations (5)Actions are missing, generic ("be more careful"), or unowned.
Writing: length, sections, causes tied to events10 pointsOutcomes: SO3	Exceeds Expectations (10)2 to 3 pages; the required sections present and in order; every stated cause or fix is tied to an event in the timeline. Meets Expectations (8)One of the three missing. Does Not Meet Expectations (2)Two or more of the three missing.

Activities That Prepare This

Fishbone Diagram for reaching root causes past the first answer, and Rehearse a Performance Conversation for the blameless criterion, which is largely a matter of language discipline. Audit Your Safety Net helps make corrective actions specific and verifiable.

Browse Planning and Risk and Team and Workflow when these run out.