postmortem

A postmortem is a written record a team produces after a serious incident, such as an outage or a security breach, that reconstructs what happened, why it happened, and what the team will change so the same failure doesn’t return. Also called a post-incident review (PIR) or simply an incident review, it is the standard last step of handling a production incident.

A short postmortem for a checkout outage records the impact, a minute-by-minute timeline, the underlying cause, and the fixes that came out of it:

Text 
# Postmortem: checkout 500s, 2026-06-03
Severity: SEV2
Impact:   42 minutes of elevated errors, about 8% of checkouts failed

Timeline (UTC)
  14:02  payments v3.1 deploy goes out
  14:09  error-rate alert fires, on-call engineer paged
  14:23  cause traced to a config key never set in production
  14:44  rollback complete, error rate back to baseline

Root cause: the release read a required config value that existed in
            staging but had never been added to production.

Action items
  - add the key to the production deploy checklist        (owner: dana)
  - fail boot on any missing required config              (owner: sam)

The document is descriptive at the top and prescriptive at the bottom. The timeline and root cause establish the facts, and the action items turn those facts into work the team commits to, which gives the document a clear shape:

A teal "Postmortem" box branches into three white boxes (Impact, Timeline, Root cause) that converge into a yellow "Action items" box, which flows down to "Runbook updates, alerts, debt paydown".
The descriptive facts feed the action items, the part that turns an incident into committed work.

How It Shows Up in Practice

A Python developer usually meets a postmortem after an incident crosses a severity threshold, once the team agrees the failure was big enough to write up. Someone who worked the response drafts the document from a shared template, and the whole team reviews it together instead of leaving it with a single author.

The raw material comes from systems the team already runs. The timeline is rebuilt from observability data, deploy logs, and the incident chat channel, and the impact line often measures how much error budget the event burned.

The finished write-up lands somewhere durable, such as a wiki page, a Markdown file in the repo, or a dedicated tool like incident.io or FireHydrant.

The most valuable part is the action-item list, because a postmortem that produces no changes is only paperwork. Those items frequently become runbook updates, new alerts, or tickets that pay down the technical debt that let the incident happen in the first place.

Blameless by Default

Most teams now run blameless postmortems, which examine the systems and processes that allowed a failure instead of looking for a person to fault. The premise is that engineers act reasonably given what they knew at the time, so an outage points to a gap in tooling, tests, or process rather than to individual carelessness.

The reason is practical as much as cultural. When people expect to be blamed, they share less, and the team loses the very details that would prevent the next outage. A blameless write-up keeps the focus on the system, noting that the deploy step let an unset config reach production rather than naming whoever ran it, which keeps accounts honest and produces fixes that hold.

This incident-driven write-up is distinct from a sprint retrospective, which revisits how the team works on a fixed cadence rather than reacting to a single failure. To read about that recurring version of the same learn-and-improve habit, see retrospective.

Logging in Python

Tutorial

Logging in Python

If you use Python's print() function to get information about the flow of your programs, logging is the natural next step. Create your first logs and curate them to grow with your projects.

intermediate best-practices stdlib tools

For additional information on related topics, take a look at the following resources:

By Martin Breuss • Updated June 22, 2026
Software Engineering Glossary Share Feedback