Post-mortem incident analysis is a structured review, conducted after the stabilization of a significant failure, to record what happened, evaluate the response, identify contributing factors, and convert the learning into corrective and preventive actions. Its goal is not to find culprits, but to reduce recurrences, improve responsiveness, and strengthen the reliability of services.<\/p>\n
In complex digital operations, restoring service only concludes the emergency phase. The organization still needs to understand why existing controls failed to prevent the incident, why detection occurred at that time, which decisions accelerated or delayed recovery, and which changes should be prioritized. Without this cycle, incidents are operationally closed but remain open from a risk perspective.<\/p>\n
Post-mortem incident analysis\u2014also called postmortem, post-incident review, or post-incident review (PIR)\u2014is a formal learning process conducted after an outage, degradation, security breach, change error, or other event with a significant impact. It integrates the lifecycle of IT service management (ITSM)<\/a> and complements incident management.<\/p>\n The result is typically a report that consolidates:<\/p>\n Post-mortem analysis does not replace incident management. During an incident, the priority is to restore service and reduce the impact. After stabilization, post-mortem analysis creates space for a more in-depth, evidence-based analysis, free from the pressure of emergency response.<\/p>\n The Latin expression post mortem means "after death." In technology, the term has been incorporated figuratively to represent the analysis performed after an incident has been closed. The use of the term does not imply that the system has been permanently lost.<\/p>\n A post-mortem can be conducted after complete outages, performance degradations, intermittent failures, security incidents, deployment errors, or situations where the company narrowly avoided a greater impact. The terms post-incident review (PIR), post-incident review, post-incident report, and incident retrospective are also used. Although there are differences in terminology between organizations, they all describe a learning mechanism following an operational failure.<\/p>\n These concepts are related, but not equivalent. Mixing them up produces incomplete analyses or actions lacking governance. The following table separates the objective, expected outcome, and scope of each practice.<\/p>\n A comprehensive post-mortem report can include a root cause analysis, generate a problem log, and recommend technical or procedural changes. However, it should also analyze response performance, communication quality, detection effectiveness, and areas where the organization was fortunate.<\/p>\n Problem management practices, in turn, do not depend exclusively on a serious incident. They can also investigate risks, trends, recurring failures, and potential causes before a major disruption occurs.<\/p>\n Not every operational call requires a formal review. The organization should define objective criteria to avoid two extremes: analyzing everything with excessive bureaucracy or reviewing only the most visible failures. A post-mortem review is usually indicated when at least one of the following conditions occurs:<\/p>\n A mature practice also reviews "near misses." When an error doesn't have an impact simply because there was idle capacity, an operator noticed the error manually, or a customer didn't execute a particular transaction, relevant learning occurs before the next occurrence.<\/p>\n A blameless postmortem assumes that people made decisions based on the information, tools, incentives, and constraints available at that time. This does not eliminate professional responsibility: the difference lies in investigating the system that allowed the error, rather than concluding the analysis by identifying a person who performed an incorrect action.<\/p>\n Google's Site Reliability Engineering culture treats this non-punitive approach as a mechanism for learning and resilience. Analysis should focus on contributing causes, environmental conditions, and barriers that failed, without subjecting individuals to personal judgment. In practice, this means replacing questions like "who caused the incident?", "why didn't the analyst notice?", or "who approved this change?" with more helpful questions:<\/p>\n The goal is not to absolve inappropriate behavior, deliberate negligence, or policy violations. These matters should follow the appropriate governance mechanisms. The operational post-mortem, however, should not be transformed into a disciplinary process.<\/p>\n An effective post-mortem combines technical evidence, multidisciplinary participation, neutral facilitation, and governance of actions. The process can be organized into eight steps.<\/p>\n The review should begin with a clear definition of the incident being analyzed, the period covered, and the participating teams. It is also advisable to appoint a facilitator who is not overly involved in the operational decisions of the event. The facilitator organizes evidence, conducts the meeting, avoids personal judgments, and ensures that disagreements are recorded objectively.<\/p>\n Before logs expire, environments change, or records are lost, the organization must preserve:<\/p>\n The report should not be built solely on individual memories. Perceptions are important, but they need to be confronted with data and records.<\/p>\n The timeline organizes events in a verifiable sequence. It should begin before the first alert, whenever possible, and include the condition that preceded the incident, the estimated start of the impact, the first observable sign, detection, team activation, classification and escalation, relevant decisions, mitigation attempts, partial recovery, full restoration, service validation, and closure communication.<\/p>\n It is also helpful to separate three timeframes: when the failure began, when the organization was able to observe it, and when the organization initiated its response. This separation highlights gaps in monitoring, escalation processes, and idle time that a single duration indicator would obscure.<\/p>\n The impact should be described in business language, not just by technical metrics. Whenever reliable data is available, record affected services and processes, total duration and periods of degradation, users, locations or customers impacted, interrupted or delayed transactions, SLAs and SLOs violated, estimated financial loss, regulatory or security risk, volume of calls generated, recovery rework, and impact on suppliers and integrations.<\/p>\n When there is insufficient information, the report should state the limitation rather than presenting estimates as facts.<\/p>\n Complex incidents rarely have a single cause. It is more useful to map contributing factors across different dimensions.<\/p>\n The analysis can use techniques such as the Five Whys, cause-and-effect diagrams, fault tree analysis, or barrier analysis. No technique should be applied mechanically: the method serves to structure questions, not to force a simple conclusion.<\/p>\n In addition to investigating why the failure occurred, the post-mortem should assess how the organization responded. Relevant questions include: Was the severity correctly classified? Was the major incident declared at the appropriate time? Were command and communication roles clear? Were the right teams activated? Was there a single source of information? Did stakeholders receive consistent updates? Were mitigation attempts documented? Was rollback possible and tested? Was the validation of the recovery sufficient? Were there correct decisions that reduced the impact? At what points did the organization rely on luck?<\/p>\n Documenting what worked is just as important as documenting failures. Effective capabilities should be preserved, standardized, and expanded.<\/p>\n A post-mortem action needs to be specific, measurable, and linked to the identified risk. Generic recommendations, such as "improve monitoring" or "train the team," rarely produce sustainable change. Each action should include an objective description, the related risk or contributing factor, the type of action, priority, responsible party, deadline, dependencies, acceptance criteria, evidence of completion, and residual risk after implementation.<\/p>\n Actions can be classified as immediate containment, technical correction, recurrence prevention, impact reduction, improved detection, improved response, process review, training, architecture upgrade, data processing or CMDB, and supplier or contract adjustment.<\/p>\n The post-mortem process doesn't end with the publication of the report. It ends when the priority actions are executed, validated, and incorporated into operational governance. The organization must periodically review completed actions, accepted risks, blocked dependencies, recurrence of the same pattern, effectiveness of corrections, need for additional changes, and impact on reliability indicators. Without follow-up, the post-mortem becomes mere historical documentation with no operational effect.<\/p>\n A standardized model reduces omissions and allows for comparison of incidents over time.<\/p>\n The structure can be adapted to the size of the company and the criticality of the incident. The essential thing is to maintain consistency and traceability.<\/p>\n A configuration change increased the database connection consumption of a critical application. The environment operated without immediate impact, but reached its limit during a peak transaction volume. The service experienced intermittent errors until the team reverted the configuration. Contributing factors were: the load test did not represent production volume; the connection limit was not monitored; the change lacked automated rollback criteria; the dependency between the configuration and the connection pool was not documented; and the existing alert measured total unavailability, but not progressive degradation.<\/p>\n This example shows that the cause should not be reduced to the person who changed the configuration. The incident depended on a combination of insufficient testing, incomplete monitoring, lack of automation, and poor visibility into the technical dependency.<\/p>\n The volume of completed post-mortem examinations does not, in itself, demonstrate maturity. The organization must measure whether the analyses reduce risk and improve response.<\/p>\n Indicators should be analyzed by service, criticality, cause, technology, and business unit. A corporate average can mask areas with high recurrence or low operational discipline.<\/p>\n In ServiceNow, post-incident review can be integrated into the Major Incident Management cycle. After resolution, the Post Incident Report allows for the consolidation of cause, actions taken, response evaluation, and follow-up items. The Service Operations Workspace can centralize operational information, timeline, incident records, related changes, tasks, and evidence, reducing the need to reconstruct the event from scattered documents and channels.<\/p>\n A consistent architecture can link the post-mortem to the main incident and associated incidents, the problem log, known errors and workarounds, emergency or corrective changes, CMDB services and configuration items, alerts, and events. ITOM<\/a>, This sequence of processes follows the same principle that underpins remediation tasks, knowledge base, risks and exceptions, and Major Incident Management indicators. IT operations automation with ServiceNow<\/a>.<\/p>\n ServiceNow documentation also describes an AI agent to generate an initial version of the post-incident review after the resolution of a major incident. The generated report should be reviewed and adjusted by responsible professionals. AI can accelerate log synthesis, but it does not replace technical validation, context analysis, accountability for actions, or governance over sensitive data.<\/p>\n The quality of the post-mortem depends directly on the quality of the information recorded during the incident. An integrated platform does not compensate for an outdated CMDB, incomplete work notes, unrecorded decisions, or alerts lacking service context.<\/p>\n\n
What does "post mortem" mean in the context of IT?<\/h2>\n
What is the difference between post-mortem, PIR, RCA, and Problem Management?<\/h2>\n
\n\n
\n \nConcept<\/th>\n Main objective<\/th>\n Expected result<\/th>\n Scope<\/th>\n<\/tr>\n<\/thead>\n \n Post-mortem<\/td>\n Learning from the incident from start to finish.<\/td>\n Report, decisions and action plan<\/td>\n Impact, detection, response, recovery, and prevention<\/td>\n<\/tr>\n \n Post-Incident Review (PIR)<\/td>\n Formally review an incident after its resolution.<\/td>\n Structured review log<\/td>\n Typically associated with the Major Incident Management cycle.<\/td>\n<\/tr>\n \n Root Cause Analysis (RCA)<\/td>\n Investigate causes and contributing factors.<\/td>\n Hypotheses supported by evidence<\/td>\n Analytical component of post-mortem or problem management.<\/td>\n<\/tr>\n \n Problem Management<\/td>\n Reduce the likelihood and impact of incidents.<\/td>\n Problems, known errors, workarounds, and permanent fixes.<\/td>\n Continuous management of real and potential causes.<\/td>\n<\/tr>\n \n Operational retrospective<\/td>\n Evaluate collaboration, decisions, and work processes.<\/td>\n Improvements in the way we respond<\/td>\n People, communication, coordination and process<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n When should an incident warrant a post-mortem?<\/h2>\n
\n
What is a post-mortem without assigning blame?<\/h2>\n
\n
How to write a post-mortem of an incident?<\/h2>\n
1. Define the scope and the facilitator.<\/h3>\n
2. Preserve evidence<\/h3>\n
\n
3. Construct the timeline<\/h3>\n
4. Quantify the impact<\/h3>\n
5. Identify contributing factors<\/h3>\n
\n\n
\n \nDimension<\/th>\n Examples of factors<\/th>\n<\/tr>\n<\/thead>\n \n Technology<\/td>\n Defect, insufficient capacity, hidden dependency, integration failure<\/td>\n<\/tr>\n \n Data<\/td>\n Incorrect, outdated, incomplete, or unowned information.<\/td>\n<\/tr>\n \n Process<\/td>\n Inadequate approval, insufficient testing, late scheduling.<\/td>\n<\/tr>\n \n People<\/td>\n Overwork, insufficient training, ambiguous roles<\/td>\n<\/tr>\n \n Tools<\/td>\n No alert, low observability, uncontrolled automation<\/td>\n<\/tr>\n \n Architecture<\/td>\n Single point of failure, high coupling, low resilience<\/td>\n<\/tr>\n \n Suppliers<\/td>\n Incompatible SLA, external dependency, delayed communication.<\/td>\n<\/tr>\n \n Governance<\/td>\n Known risk without treatment, exceptions without a deadline, decision without evidence.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n 6. Evaluate the response to the incident.<\/h3>\n
7. Define corrective and preventive actions.<\/h3>\n
8. Approve, monitor and verify<\/h3>\n
What should be included in a post-mortem report?<\/h2>\n
\n\n
\n \nSection<\/th>\n Expected content<\/th>\n<\/tr>\n<\/thead>\n \n Identification<\/td>\n Number, title, service, severity, dates and responsible parties.<\/td>\n<\/tr>\n \n Summary<\/td>\n Objective description of the incident and current situation.<\/td>\n<\/tr>\n \n Impact<\/td>\n Services, users, transactions, duration and consequences<\/td>\n<\/tr>\n \n Detection<\/td>\n How, when, and by whom was the incident identified?<\/td>\n<\/tr>\n \n Timeline<\/td>\n Factual sequence of events, decisions, and communications.<\/td>\n<\/tr>\n \n Response<\/td>\n Actions taken to contain, mitigate and recover<\/td>\n<\/tr>\n \n Contributing factors<\/td>\n Technical, procedural and organizational conditions<\/td>\n<\/tr>\n \n Cause or causes<\/td>\n Conclusion supported by available evidence.<\/td>\n<\/tr>\n \n What worked<\/td>\n Controls and decisions that reduced the impact<\/td>\n<\/tr>\n \n What didn't work<\/td>\n Technology, process, data, and governance gaps<\/td>\n<\/tr>\n \n Where there was luck<\/td>\n Uncontrolled conditions that prevented a greater impact.<\/td>\n<\/tr>\n \n Actions<\/td>\n Measures, responsibilities, deadlines and acceptance criteria<\/td>\n<\/tr>\n \n Residual risk<\/td>\n Exhibition that remains after the planned actions.<\/td>\n<\/tr>\n \n Approval<\/td>\n Participants, reviewers, and closure decision<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Simplified example of a post-mortem<\/h2>\n
\n\n
\n \nAction<\/th>\n Responsible<\/th>\n Term<\/th>\n Acceptance criteria<\/th>\n<\/tr>\n<\/thead>\n \n Create an alert for pool saturation.<\/td>\n Observability<\/td>\n 15 days<\/td>\n Alert validated in controlled testing.<\/td>\n<\/tr>\n \n Update load test scenario<\/td>\n Engineering<\/td>\n 30 days<\/td>\n Peak volume reproduced with evidence<\/td>\n<\/tr>\n \n Automate configuration rollback<\/td>\n DevOps<\/td>\n 30 days<\/td>\n Pipeline reverting change in test.<\/td>\n<\/tr>\n \n Register dependency in CMDB<\/td>\n Configuration Management<\/td>\n 10 days<\/td>\n Relationship validated by the service owner.<\/td>\n<\/tr>\n \n Review change pattern<\/td>\n Change Management<\/td>\n 45 days<\/td>\n New control approved and published.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Which indicators should be monitored?<\/h2>\n
\n\n
\n \nIndicator<\/th>\n Which demonstrates<\/th>\n<\/tr>\n<\/thead>\n \n Percentage of eligible incidents with post-mortem<\/td>\n Adherence to the process<\/td>\n<\/tr>\n \n Time between resolution and review<\/td>\n Learning speed<\/td>\n<\/tr>\n \n Percentage of actions completed on time.<\/td>\n Execution capacity<\/td>\n<\/tr>\n \n Average age of open stocks<\/td>\n Accumulation of risk<\/td>\n<\/tr>\n \n Recurrence rate<\/td>\n Effectiveness of the corrections<\/td>\n<\/tr>\n \n Average detection time<\/td>\n Monitoring quality and observability<\/td>\n<\/tr>\n \n Average restoration time<\/td>\n Response efficiency<\/td>\n<\/tr>\n \n Incidents detected by users<\/td>\n Internal detection gaps<\/td>\n<\/tr>\n \n Percentage of prevention actions versus documentation<\/td>\n Depth of treatment<\/td>\n<\/tr>\n \n Incidents with inconclusive cause<\/td>\n Limitations of evidence and investigation<\/td>\n<\/tr>\n \n Accepted residual risk<\/td>\n Governance transparency<\/td>\n<\/tr>\n \n Recurring patterns across services<\/td>\n Systemic or architectural problems<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n How does ServiceNow support post-mortem?<\/h2>\n
What is the role of CMDB in the post-mortem?<\/h2>\n