Rootly Postmortems

Rootly Postmortems

Overview

Postmortems in Rootly are structured retrospectives created after incidents are resolved. They document what happened, why it happened, and what will be done to prevent recurrence. Rootly supports templates, automatic timeline import, action item tracking, and integration with project management tools for follow-through.

Anti-triggers

• The resolution note a customer reads — a PSA ticket's resolution field is a customer-facing summary written to close the ticket, not a blameless internal retrospective. Use halopsa-tickets, freshdesk-ticketing, or connectwise-psa-tickets.
• A security incident write-up — Huntress ships its own SOC investigation detail on the incident record; use huntress-incidents.
• The live incident — status, severity, and response coordination while it is still open are rootly-incidents. This skill starts after resolution.
• Automating postmortem creation — the trigger that fires on incident_resolved is a workflow; use rootly-workflows.
• Publishing the retrospective as customer documentation — MSP knowledge bases are hudu-articles or itglue-documents.
• The vendor-agnostic retrospective process — how to run the review, structure findings, and track actions whatever incident tool the client uses is devops-pack-incident-postmortem; this skill is the Rootly postmortem API behind it.

Key Concepts

Postmortem Lifecycle

1. Draft -- Postmortem created, content being assembled
2. In Review -- Team reviewing and adding context
3. Published -- Finalized and shared with stakeholders
4. Completed -- All action items resolved

Postmortem Sections

A typical Rootly postmortem includes:

• Summary -- What happened in plain language
• Timeline -- Chronological events (auto-imported from incident)
• Root Cause -- Why the incident occurred
• Impact -- Users, services, and duration affected
• Detection -- How the incident was discovered
• Response -- Steps taken to mitigate and resolve
• Lessons Learned -- What went well and what didn't
• Action Items -- Concrete follow-up tasks with owners and due dates

Action Items

Action items are the most important output of a postmortem:

• Priority -- Critical, high, medium, low
• Status -- Open, in progress, completed
• Assignee -- Person responsible
• Due Date -- Target completion date
• Type -- Prevention, detection, process, documentation

API Patterns

List Postmortems

rootly_list_postmortems

Parameters:

• incident_id -- Filter by incident
• status -- Filter by status (draft, in_review, published, completed)

Example response:

{
  "data": [
    {
      "id": "pm-101",
      "type": "postmortems",
      "attributes": {
        "title": "Payment Processing Outage - 2026-03-25",
        "status": "in_review",
        "incident_id": "inc-456",
        "created_at": "2026-03-26T10:00:00Z",
        "summary": "Payment webhooks timed out due to database connection pool exhaustion",
        "action_items_count": 4,
        "action_items_completed": 1
      }
    }
  ]
}

Get Postmortem Details

rootly_get_postmortem

Parameters:

• postmortem_id -- The postmortem ID

Create Postmortem

rootly_create_postmortem

Parameters:

• incident_id -- The incident to create a postmortem for
• title -- Postmortem title
• template_id -- Optional template to use

Update Postmortem

rootly_update_postmortem

Parameters:

• postmortem_id -- The postmortem ID
• summary -- Updated summary
• root_cause -- Root cause analysis
• impact -- Impact description
• status -- Updated status

List Action Items

rootly_list_action_items

Parameters:

• incident_id -- Filter by incident
• status -- Filter by status (open, in_progress, completed)
• assignee -- Filter by assignee

Create Action Item

rootly_create_action_item

Parameters:

• incident_id -- The incident ID
• title -- Action item title
• description -- Detailed description
• priority -- Priority level
• assignee_id -- Assigned user
• due_date -- Target completion date

Update Action Item

rootly_update_action_item

Parameters:

• action_item_id -- The action item ID
• status -- Updated status
• assignee_id -- Updated assignee

Common Workflows

Create Postmortem After Incident

1. Get resolved incident details with rootly_get_incident
2. Create postmortem with rootly_create_postmortem (timeline auto-imports)
3. Fill in root cause, impact, and lessons learned sections
4. Create action items for each follow-up task
5. Set postmortem status to "in_review"

Generate Postmortem Summary

1. Get incident details and timeline
2. Get postmortem content with rootly_get_postmortem
3. Summarize key findings: root cause, impact duration, affected services
4. List action items with status and ownership
5. Highlight overdue or unassigned items

Track Outstanding Action Items

1. Call rootly_list_action_items with status=open
2. Group by priority and assignee
3. Flag overdue items (past due date)
4. Identify incidents with no action items (gap in follow-through)
5. Report completion rates and trends

Error Handling

Postmortem Not Found

Cause: Invalid postmortem ID or postmortem deleted Solution: List postmortems for the incident to verify the ID

Incident Not Resolved

Cause: Attempting to create a postmortem for an active incident Solution: Resolve the incident first, then create the postmortem

Duplicate Postmortem

Cause: Postmortem already exists for this incident Solution: Get the existing postmortem instead of creating a new one

Best Practices

• Create postmortems within 48 hours of incident resolution
• Keep postmortems blameless -- focus on systems, not individuals
• Include both "what went well" and "what could be improved"
• Assign every action item to a specific person with a due date
• Review open action items weekly in team standups
• Use templates for consistency across postmortems
• Link related incidents to identify recurring patterns
• Track action item completion rates as a reliability metric

Related Skills

• api-patterns - Pagination and error handling
• incidents - Incident context for postmortems
• services - Affected service information
• workflows - Automated postmortem creation workflows