Stage 6 · Operate
Incident Response & On-Call
Postmortem Facilitation
Blameless timelines, contributing factors, action-item owners, and recurrence metrics.
The Facilitator Role
The postmortem facilitator guides the review meeting. They keep the conversation blameless, ensure all voices are heard, and drive toward actionable outcomes. The facilitator should not be the incident commander or the primary investigator.
The facilitator has no stake in the outcome. They are not defending a decision or assigning blame. Their job is to ensure the team learns from the incident. Choose someone who was not directly involved in the incident.
Meeting Structure
postmortem_meeting:
duration: "60 minutes"
participants:
- "Incident Commander"
- "Operations Lead"
- "Communications Lead"
- "Scribe"
- "Facilitator"
- "Relevant engineers"
- "Optional: stakeholders"
agenda:
- time: "0-5 min"
item: "Facilitator sets ground rules"
details: "Blameless, focus on systems, all perspectives welcome"
- time: "5-15 min"
item: "Timeline review"
details: "Walk through the reconstructed timeline"
- time: "15-25 min"
item: "Contributing factors"
details: "Identify what made the incident possible"
- time: "25-35 min"
item: "What went well / poorly"
details: "Both sides of the response"
- time: "35-50 min"
item: "Action items"
details: "Assign owners and due dates"
- time: "50-60 min"
item: "Next steps"
details: "Schedule follow-up, assign postmortem author"Blameless Timeline Review
Review the timeline without assigning blame. Focus on what happened, why it happened, and what the system allowed. When someone says 'I did X,' reframe it as 'the system allowed X to happen.'
blameless_reframing:
blameful: "Bob deployed on Friday and caused the outage"
blameless: "The deployment process allowed a Friday deploy without additional safeguards"
blameful: "Alice missed the alert"
blameless: "The alert fired at 3 AM and Alice was asleep. The escalation policy did not have a backup."
blameful: "The team did not have a runbook"
blameless: "There was no process for ensuring runbooks existed for critical services"
blameful: "Charlie did not check disk space"
blameless: "Disk space monitoring was not configured for this service"
blameful: "The deploy was rushed"
blameless: "The deployment process did not require staging validation for this type of change"Identifying Contributing Factors
Contributing factors are the conditions that made the incident possible. They are not root causes — they are the soil in which root causes grow. Identifying them helps you address systemic issues.
contributing_factors:
technical:
- "No circuit breaker for database connections"
- "No connection pool monitoring"
- "No auto-scaling for connection pools"
process:
- "No pre-deploy validation checklist"
- "No capacity review process"
- "No standard application metrics"
human:
- "Original config set by engineer who left"
- "No documentation of configuration rationale"
- "No handoff process for configuration ownership"
organizational:
- "No SLO for database connection availability"
- "No regular capacity planning reviews"
- "No standard onboarding for new services"
environmental:
- "Traffic spike from marketing campaign"
- "Holiday weekend with reduced staffing"
- "Cloud provider had regional issues"Action Item Assignment
Assign action items during the meeting, not after. Use the SMART framework: Specific, Measurable, Achievable, Relevant, Time-bound. Each item must have exactly one owner and a realistic due date.
action_item_process:
during_meeting:
- "Identify action items from contributing factors"
- "Write each item clearly on the shared document"
- "Ask: 'Who will own this?' — wait for explicit commitment"
- "Set due date with owner's input"
- "Verify success criteria is clear"
after_meeting:
- "Author creates draft postmortem within 2 business days"
- "Facilitator reviews draft for blameless language"
- "Distribute to participants for review"
- "Schedule follow-up meeting for action item review"
quality_checks:
- "Is there exactly one owner?"
- "Is the due date realistic?"
- "Is the success criteria measurable?"
- "Is the action specific enough to execute?"
- "Does the action address a contributing factor?"Recurrence Metrics
Track whether your postmortems are preventing recurrence. If the same incident type keeps happening, your postmortem process is not producing effective action items. Measure recurrence to improve your process.
recurrence_metrics:
- name: "Incident Recurrence Rate"
formula: "incidents_with_prior_postmortem / total_incidents"
target: "< 10%"
frequency: "Monthly"
- name: "Action Item Completion Rate"
formula: "completed_actions / total_actions"
target: "> 90%"
frequency: "Monthly"
- name: "Mean Time to Action Completion"
formula: "avg(completed_date - created_date)"
target: "< 30 days"
frequency: "Monthly"
- name: "Postmortem Quality Score"
criteria:
- "Blameless language used throughout"
- "Timeline reconstructed from multiple sources"
- "Contributing factors identified at system level"
- "All action items have owners and due dates"
- "Reviewed within 5 business days"
target: "100% compliance"
frequency: "Per postmortem"If the same type of incident happens twice, your postmortem process failed to prevent it. Investigate why: were action items ineffective? Were they not completed? Was the root cause misidentified? Improve the process, not just the action items.
Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.