A postmortem is the act of holding a retrospective after a service incident. Depending on the organization, a postmortem is called by many names—retrospective, root cause analysis (RCA), incident review, and others. The idea is to create a document that records why an incident happened and discuss what happened with those involved.

The term postmortem is usually connected to the medical or judicial professions. It is defined by the Oxford English Dictionary as "an examination of a dead body to determine the cause of death." This definition is the reason that many people in software use the term postmortem. Some view software processes as living things and so, when a process stops, it is described as dead. Those who find the idea of ascribing life to a machine to be problematic often use the terms incident review or RCA. Whatever the term used, the goal is to create a historical artifact and discuss the incident that happened.

I mentioned the term retrospective, which a postmortem is, but retrospective is often a more general term used for any process that looks back on a period. A typical time to have a retrospective is at the end of a quarter, right before a planning meeting, or at the end of a week. Many people also do personal retrospectives. This can involve looking at their lives and deciding what they can improve, what they want to keep the same, and what they want to stop doing. Postmortems are more focused, dealing with a specific event, but they follow a similar structure of evaluation.

Figure 1: Our current position in the hierarchy

Postmortems, understandably, follow incident response. In this chapter, we will talk about why it is important to write a postmortem document after an incident, how to write one, and how to hold a postmortem meeting.