Skip to main content

Overview

Postmortems (Post-Incident Reviews) enable your team to analyze resolved incidents, identify root causes, and create action items to prevent similar incidents in the future. With a blameless approach, rich editing capabilities, and comprehensive tracking, you can build a culture of continuous improvement.

Blameless Culture

Focus on processes and systems, not individuals

Timeline Builder

Document key events with precise timestamps

Action Tracking

Create and track action items with assignments

PDF Export

Generate professional reports for stakeholders

Postmortem Workflow

A typical postmortem follows this lifecycle:
Incident Resolved

   Create Postmortem (Draft)

   Link Related Incidents

   Build Timeline

   Document Analysis (Root Causes, Learnings)

   Create Action Items

   Submit for Review

   Publish

   Track Action Item Completion

Viewing Postmortems

The Postmortems page displays all your post-incident reviews:
ColumnDescription
TitlePostmortem name and linked incident count
StatusDraft, In Review, or Published
SeverityCritical, High, Medium, or Low
OwnerPerson responsible for the postmortem
CreatedWhen the postmortem was created
ActionsView, Edit, Delete

Statistics Cards

The page header shows key metrics:
  • Total — All postmortems
  • Draft — Work in progress
  • In Review — Awaiting approval
  • Published — Completed and shared
  • Open Actions — Pending action items across all postmortems

Creating a Postmortem

1

Open Create Dialog

Click the Create Postmortem button
2

Enter Basic Information

  • Title — Descriptive name for the postmortem
  • Primary Incident — Select the main incident to analyze (optional)
3

Create

Click Create to open the editor

Postmortem Editor

The editor is organized into tabs for different aspects of the postmortem:

Overview Tab

Configure basic information and link incidents:
Severity — Impact level of the incident
  • Critical, High, Medium, Low
Incident Type — Category of the incident
  • Outage, Degradation, Security, Data Loss

Linked Incidents

Connect EasyAlert incidents to the postmortem:
  1. Click + (Add) in the Linked Incidents card
  2. Search for incidents by title, number, or description
  3. Click an incident to link it
  4. Mark one incident as Primary if multiple are linked
Linking incidents provides context and allows you to reference timeline events from the original incident.

Timeline Tab

Document the sequence of events during the incident:
1

Add Entry

Click Add Entry to create a new timeline event
2

Configure Event

  • When — Date and time of the event
  • Title — What happened
  • Event Type — Detection, Escalation, Mitigation, Resolution, Communication, Decision
  • Description — Additional details
  • Actor Role — Who was involved (blameless: “On-call Engineer” not “John”)
  • Key Moment — Toggle to highlight critical events
3

Save

Click Add Entry to save

Event Types

TypeDescription
DetectionWhen the issue was first noticed
EscalationWhen additional help was requested
MitigationActions taken to reduce impact
ResolutionSteps that fixed the issue
CommunicationUpdates sent to stakeholders
DecisionKey decisions made during response
Key moments are highlighted in the timeline and emphasized in PDF exports.

Analysis Tab

Identify and document root causes:
1

Add Root Cause

Click Add Cause to create a new entry
2

Document the Cause

  • Cause — What went wrong
  • Category — Technical, Process, Human, or External
  • Description — Detailed explanation

Root Cause Categories

CategoryExamples
TechnicalBug, configuration error, capacity issue
ProcessMissing runbook, unclear ownership, deployment issue
HumanMiscommunication, oversight, training gap
ExternalThird-party outage, network issues, vendor problem
Focus on systemic issues rather than individual mistakes. Ask “Why did the system allow this?” not “Who made this mistake?”

Learnings Tab

Document what worked well and what needs improvement:

What Went Well

Capture positive aspects of the incident response:
  • Quick detection
  • Effective communication
  • Good collaboration
  • Useful runbooks
Each item can have:
  • Title — What went well
  • Details — Description (supports longer text)

What Didn’t Go Well

Identify areas for improvement:
  • Slow detection
  • Missing documentation
  • Communication gaps
  • Tooling issues
Each item can have:
  • Title — What didn’t go well
  • How can we improve? — Suggested improvement (supports longer text)

Lessons Learned

Key takeaways from the incident:
  • Click Add Lesson to create entries
  • Focus on actionable insights
  • These appear prominently in the published view

Actions Tab

Create tasks to prevent similar incidents:
1

Add Action Item

Click Add Action Item
2

Configure Details

  • Title — What needs to be done
  • Description — Additional context
  • Priority — Critical, High, Medium, Low
  • Category — Process, Tooling, Monitoring, Documentation, Training
  • Assignee — Person responsible
  • Due Date — Target completion date (with calendar picker)
3

Save

Click Add to create the action item

Action Item Status

StatusDescription
OpenNot started
In ProgressCurrently being worked on
CompletedFinished
Won’t FixDecided not to implement
Review action items regularly. Unresolved items undermine the value of postmortems.

Team Tab

Add contributors who participated in the postmortem:
1

Add Contributor

Click Add Contributor
2

Select Details

  • User — Select team member
  • Role — Owner, Facilitator, Scribe, Contributor, Reviewer
  • Role Description — Optional details (e.g., “Database SME”)

Contributor Roles

RoleResponsibility
OwnerLeads the postmortem, ensures completion
FacilitatorGuides the postmortem meeting
ScribeDocuments discussions and findings
ContributorProvides input and expertise
ReviewerReviews before publication

Postmortem Status

Draft

  • Initial state when created
  • Full editing capabilities
  • Not visible to broader team
  • Can be saved incrementally

In Review

  • Submitted for approval
  • Limited editing
  • Reviewers can add comments
  • Requires approval to publish
To submit for review:
  1. Click Submit for Review
  2. Confirm the action
  3. Status changes to “In Review”

Published

  • Finalized and shared
  • Read-only (no editing)
  • Visible to all team members
  • Can be exported as PDF
To publish:
  1. Ensure status is “In Review”
  2. Click Publish
  3. Confirm the action
  4. Redirected to view page

Viewing Published Postmortems

The view page presents the postmortem in a professional format:
  • Header — Title, severity, status, owner
  • Overview — Summary and key details
  • Timeline — Visual timeline of events
  • Root Causes — Categorized causes
  • Learnings — What went well/didn’t go well
  • Action Items — Status and assignments
  • Contributors — Team members involved

PDF Export

Generate a professional PDF document for stakeholders:
1

Open Postmortem

Navigate to the postmortem view page
2

Export

Click the Export PDF button
3

Download

PDF downloads automatically
The PDF includes:
  • Professional header with EasyAlert branding
  • All sections formatted for print
  • Timeline with key moments highlighted
  • Action items table
  • Contributors list
  • Page numbers and footer
PDFs are ideal for sharing with stakeholders who don’t have EasyAlert access or for archival purposes.

Best Practices

Focus on systems and processes, not individuals. Ask “How did the system allow this?” rather than “Who caused this?”
Aim to complete postmortems within 5-7 days while details are fresh. Set a calendar reminder after resolving major incidents.
Include all significant events, not just the obvious ones. Detection, communication, and decision points are often as important as technical actions.
Most incidents have contributing factors across multiple categories. A technical bug might be enabled by a process gap.
“Improve monitoring” is too vague. “Add alert for database connection pool exhaustion” is actionable and measurable.
Action items without owners don’t get done. Set realistic due dates and follow up regularly.
Publish postmortems to the whole team. Others can learn from incidents they weren’t involved in.
Periodically review past postmortems. Are similar incidents recurring? Are action items being completed?

Common Patterns

Timeline Focus: Detection time, escalation path, mitigation stepsRoot Causes: Often technical + process (e.g., config change without review)Action Items: Improved monitoring, rollback procedures, change management
Timeline Focus: When degradation started, customer impact, resolutionRoot Causes: Capacity planning, load testing gaps, monitoring blindspotsAction Items: Capacity alerts, load testing, performance baselines
Timeline Focus: Initial compromise, detection, containment, remediationRoot Causes: Vulnerability, access control, detection gapsAction Items: Patching, access review, security monitoring
Timeline Focus: When issue occurred, detection, data recoveryRoot Causes: Backup gaps, validation missing, process failuresAction Items: Backup verification, data validation, recovery testing

Troubleshooting

  • Clear browser cache and retry
  • Try a different browser
  • Ensure postmortem has content to export
Published postmortems are read-only. Contact an admin if corrections are needed.
  • Ensure required fields (Title) are filled
  • Check for validation errors
  • Save postmortem before adding action items
  • Verify user exists in the tenant
  • Check user has appropriate permissions
  • Try searching by email if name doesn’t work

Quick Reference

Postmortem Statuses

StatusCan EditVisible ToNext Action
DraftYesOwner onlySubmit for Review
In ReviewLimitedReviewersPublish
PublishedNoAll teamExport PDF

Severity Levels

SeverityImpactExample
CriticalComplete service outageProduction down
HighMajor functionality impairedCore feature broken
MediumLimited impactNon-critical feature affected
LowMinimal impactMinor issue

Action Item Priorities

PriorityResponse TimeExample
CriticalImmediateSecurity vulnerability
HighThis sprintMajor process improvement
MediumThis quarterDocumentation update
LowBacklogNice-to-have enhancement