Postmortem
A postmortem is a retrospective analysis of an event or incident that examines what happened, its causes and effects, and lessons or actions for improvement.
Troubleshooting Java, Second Edition
A postmortem investigation is troubleshooting performed after an application has crashed and stopped running.
- How it is used
- Deploys troubleshooting after an application crash, particularly when a production service has stopped running.
- How deep it goes
- Defines the technique and identifies evidence sources, but defers detailed dump analysis and implementation procedures.
- Examples
- Uses production crashes, memory errors, large log files, and database-lock exceptions as investigative examples.
- What you can do after
- Diagnose crash causes by correlating logs, heap dumps, thread dumps, and other evidence collected around the failure.
Read how Troubleshooting Java, Second Edition explains postmortem →
Machine Learning System Design
A postmortem is a structured analysis of an incident and its causes, effects, and follow-up actions.
- How it is used
- Turns production failures into learning, corrective actions, and improved reliability.
- How deep it goes
- Defines retrospectives, postmortems, and proportional response, but stops short of prescribing a detailed investigation template.
- Examples
- Uses minor incidents requiring runbook updates and a major outage prompting a company-wide reliability initiative.
- What you can do after
- Practice proportional postincident learning and convert failures into appropriately sized follow-up actions.
Read how Machine Learning System Design explains postmortem →
Think Like a CTO
A postmortem is a structured review conducted after an event to examine what happened, what went well, and what should improve.
- How it is used
- Reviews releases and incidents after completion to recognize successes, learn from failures, and examine preventable problems.
- How deep it goes
- Distinguishes planning failures from hindsight, checks leadership authorization, and recommends documenting events and addressing recurring issues.
- Examples
- Uses release completion, security breaches, data loss, payment-related service loss, and hardware failure as review cases.
- What you can do after
- Apply it by documenting an event, consulting the responsible person, and considering training or role changes when problems recur.
Related concepts
- trustcontrasts with · Trust is confidence that a person, organization, system, or source is reliable and will act or behave appropriately in a given context.
- monitoringuses · Monitoring is the ongoing observation and measurement of a system’s behavior, state, or operational signals to assess its condition and detect changes or problems.
- root causeuses · A root cause is an underlying condition or factor that produces or substantially contributes to an observed problem, failure, or outcome.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.