A postmortem is a structured review after incidents or failed releases. It documents causes, impacts and actions, promotes a learning culture and helps prevent recurring issues. The goal is sustainable improvement of processes and system reliability.
Use this profile to understand the building block briefly, place it in the model, and switch to the 360° assessment when needed.
Executable approach: can be applied and produces an outcome.
What you need to understand to reason about a domain.
A postmortem reviews an incident after the fact, records impact and causes, and derives verifiable improvements.
The term comes from medical review of a death and was adopted in software practice for structured incident retrospectives. There is no single author for this general practice; SRE and DevOps teams shaped its current use.
Start with a reliable timeline and the user or business impact. Separate immediate triggers from contributing conditions, examine detection and response, and define a few actions with owners and dates. Keep the review learning-oriented by examining systems, decisions, and safeguards.
Observed harm shows who or what the incident affected.
Chronological events make the course and decision points traceable.
Owned, concrete changes reduce the likelihood or impact of recurrence.
Postmortems turn operational failures into organizational learning. Their value depends on evidence, psychological safety, and followed-through actions; assigning blame alone damages reporting culture and reliability.
Where this building block is located in the topic model.
Explore how this building block connects to concepts, methods, technologies, and tools.
These sources establish the term and its professional meaning.
All direct connections of the current building block in a compact text view.
This classification shows where the building block typically matters, how demanding it is, and what kind of impact it has in the model.
The level within the organization (enterprise, domain, team) at which the AssetBlock is applied.