/postmortems

name: "Rootly Postmortems"
description: >
  Rootly postmortems as structured post-incident retrospectives: Rootly's retrospective
  process/step model (there is no standalone "postmortem" object), per-step status
  tracking through to completion, action item creation and tracking, and the
  blameless review practices Rootly's model assumes.
when_to_use: >-
  When writing a retrospective for a resolved Rootly incident or tracking its follow-up
  action items. Use when: rootly postmortem, retrospective,
  post-incident review, action item, blameless review, postmortem template, lessons learned, or
  incident review.

Rootly Postmortems

Overview

Postmortems in Rootly are structured retrospectives created after incidents are resolved. Rootly does not model this as a single "postmortem" document — it models it as a **retrospective process**: an ordered set of steps (e.g., write summary, identify root cause, assign action items) that each incident works through, with each step tracking its own status independently. Action items are tracked separately, both per-incident and across the whole organization.

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** — a workflow action that fires on an

incident event (e.g. `create_incident_postmortem` when the incident is resolved) is configured in `rootly-workflows`; this skill covers the retrospective steps and action items that result, not the trigger.

• **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 retrospective API behind it.

Key Concepts

Rootly Has No Single "Postmortem" Object

There is no `postmortem` resource with its own draft/review/published lifecycle. Instead, Rootly defines a **retrospective process** — a reusable template of steps — and applies it to an incident. Each incident then gets its own instance of every step in that process, and each step's completion is tracked independently.

Retrospective Structure

• **Retrospective Process** -- An org-level template (e.g., "Standard Postmortem," "SEV-1 Deep Dive") defining which steps an incident's retrospective must go through. `retrospective_process_matching_criteria` on the process determines which incidents use it (for example, by severity or incident type).
• **Retrospective Process Group** -- A logical grouping of steps inside a process, tied to an incident sub-status.
• **Retrospective Step** -- A step *definition* within a process: title, description, whether it's `skippable`, and how many days after the triggering event it's due (`due_after_days`).
• **Incident Retrospective Step** -- The actual instance of a step on one specific incident. This is the object you read and update as the retrospective progresses.

Incident Retrospective Step Status

Each `incident_retrospective_step` carries its own status, independent of the others:

• `todo`
• `in_progress`
• `completed`
• `skipped`

There is no single "postmortem status" — the retrospective's overall state is the aggregate of its steps' statuses.

Action Items

Action items are the most important output of a retrospective:

• **Kind** -- `task` or `follow_up`
• **Priority** -- `high`, `medium`, `low`
• **Status** -- `open`, `in_progress`, `cancelled`, `done`
• **Assignee** -- `assigned_to` (user) or `assigned_to_group_ids` (team)
• **Due Date** -- `due_date`
• Optional Jira linkage: `jira_issue_id`, `jira_issue_key`, `jira_issue_url`

API Patterns

List Retrospective Processes

list_retrospective_processes

Returns the org's configured retrospective process templates (name, description, whether it's the default, matching criteria).

Get Retrospective Process Details

get_retrospective_process

Parameters:

• Retrospective process ID

Get an Incident's Retrospective Step

get_incident_retrospective_step

Parameters:

• Incident retrospective step ID

**Example response shape:**

{
  "data": {
    "id": "irs-101",
    "type": "incident_retrospective_steps",
    "attributes": {
      "retrospective_step_id": "rs-9",
      "incident_id": "inc-456",
      "title": "Root Cause Analysis",
      "status": "in_progress",
      "kind": "text",
      "due_date": "2026-03-28T00:00:00Z",
      "skippable": false
    }
  }
}

Update an Incident's Retrospective Step

update_incident_retrospective_step

Parameters:

• Incident retrospective step ID
• `status` -- `todo`, `in_progress`, `completed`, or `skipped`
• `title` / `description` -- Step content
• `due_date` -- Target completion date

List Action Items on an Incident

list_incident_action_items

Parameters:

• Incident ID

List Action Items Across All Incidents

list_all_incident_action_items

Use this for org-wide action item tracking rather than one incident at a time — this is the tool behind "what's still outstanding across every retrospective."

Create an Action Item

create_incident_action_item

Parameters:

• Incident ID
• `summary` -- Action item summary (required)
• `description` -- Detailed description
• `kind` -- `task` or `follow_up`
• `priority` -- `high`, `medium`, or `low`
• `assigned_to` -- Assigned user
• `