The structured writeup produced after every Sev-1 (or higher) that captures timeline, root cause, impact, and action items.
A postmortem is the document an engineering team writes after every significant incident. A good postmortem includes: a timeline (with timestamps and actor names), customer impact (in concrete numbers, e.g. '3.4M failed checkout requests'), root cause (ideally to the systemic level via Five Whys), what worked, what didn't, and a list of action items with owners and deadlines. The postmortem is then reviewed in a meeting where the action items are agreed and tracked through to completion.
An incident without a postmortem is an incident that's going to recur. The discipline of writing the doc forces the team to actually understand what happened, and the action items are the only way new lessons cross team boundaries. Skipping postmortems for 'minor' incidents is the most common reliability anti-pattern, because the same minor pattern eventually combines with another to produce a major outage.
See the part of the platform that handles postmortem in production.