Skip to main content
Retrospectives help teams capture what happened during an incident, identify contributing factors, and track the follow-up work needed to reduce repeat issues. In Rootly, retrospectives can be customized to right-size follow-up work based on the incident. You can define which retrospective process applies, which steps are created, when a retrospective is required or skipped, how the retrospective document is generated, and which workflows run when the retrospective is created or updated.
Rootly uses the term Retrospective throughout the product, but some older workflows, variables, or integrations may still reference postmortem. Existing links and variables continue to work for backward compatibility.

​
How Retrospectives Work

A retrospective in Rootly is made up of several configurable parts:
  • Processes determine which retrospective flow applies to an incident
  • Steps define the work that responders complete
  • Preferences control when retrospectives are skipped or mandatory
  • Templates define the structure of the retrospective document
  • Workflows automate retrospective creation, updates, notifications, and external document generation
This allows teams to right-size follow-up work based on the incident’s severity, type, team, or lifecycle phase.

​
Retrospective Processes

Retrospective processes define which follow-up flow should be used for an incident. Each process can be configured to apply based on:
  • Severity
  • Incident type
  • Team
If no custom process matches, Rootly falls back to the default retrospective process. Every workspace includes a Default Retrospective process, which acts as the fallback and cannot be deleted. A custom process must have at least one condition to be used. If no severity, incident type, or team is attached, the process remains inactive.

​
Retrospective Steps

Each retrospective process contains ordered steps that guide responders through post-incident work. Steps can be configured with:
  • A title and description
  • Required or optional completion
  • A default owner based on an Incident Role
  • Due dates relative to incident resolution
  • Slack and email reminders
Common steps include:
  • Gather and confirm data
  • Write the retrospective document
  • Host a retrospective meeting
  • Create follow-up action items
  • Share the finalized retrospective
If your workspace uses Custom Statuses, steps can also be assigned to different retrospective phases, such as a retrospective phase and a follow-up phase.

​
Skip and Mandatory Preferences

Retrospective preferences control when retrospectives should be skipped or required. You can configure rules based on:
  • Severity
  • Incident type
  • Team
This lets you make retrospectives:
  • Mandatory for high-impact incidents
  • Auto-skipped for lower-impact incidents
  • Optional when no mandatory or auto-skip rule applies
By default, responders can skip a retrospective on an incident unless that retrospective is marked as mandatory. Auto-skipped retrospectives can still be resumed later using Resume retrospective on the incident if additional follow-up is needed.

​
Retrospective Templates

Retrospective templates define the content and structure of the retrospective document. Templates can be used to standardize sections such as:
  • Summary
  • Timeline
  • Impact
  • Root cause
  • Follow-up actions
You can create and manage templates under Retrospectives → Document Templates. Templates support Liquid, which allows you to dynamically insert incident and retrospective data into the document. One template can also be marked as the default. Additional resources:

​
Workflow Triggers and Automation

Rootly supports retrospective-specific workflows that run when a retrospective is created or updated. Available triggers include:
  • Retrospective Created
  • Retrospective Updated
These workflows can be used to:
  • Create or update the in-Rootly retrospective
  • Generate external documents in tools like Confluence or Google Docs
  • Send notifications when the retrospective changes
  • Apply different actions based on incident or retrospective conditions
The initial retrospective is created when the incident is resolved. Retrospective workflows can then run when that retrospective is created or later updated.
Older workflows may still use task names such as Create Incident Postmortem or Edit Postmortem. These names do not update automatically. To use the newer wording, edit the workflow task name or remove and re-add the task.

​
Retrospective Variables

In workflows, notifications, and Liquid-based templates, Rootly supports retrospective variables for linking to or referencing the retrospective. Common variables include:
  • incident.retrospective_id
  • incident.retrospective_url
  • incident.retrospective_short_url
  • incident.retrospective_progress_status
Legacy equivalents are also supported:
  • incident.postmortem_id
  • incident.postmortem_url
  • incident.postmortem_short_url
For new templates and workflows, use the retrospective_* versions where possible. Old links that use postmortem in the path continue to work and automatically redirect to the current retrospective URL.

​
Retrospective Progress Status

Retrospectives move through a progress lifecycle as responders complete the work. Common statuses include:
  • Not started
  • Active
  • Completed
  • Skipped
Use incident.retrospective_progress_status in workflows, notifications, and Liquid-based templates to reference the current progress state of the retrospective.

​
Frequently Asked Questions

A retrospective can include a process, a set of steps, a document template, workflow automation, and preference rules that determine whether the retrospective is required, optional, or skipped. Together, these settings define how post-incident follow-up is managed in Rootly.
The initial retrospective is created when an incident is resolved. After that, retrospective workflows can run when the retrospective is created or updated.
Rootly checks the conditions attached to custom retrospective processes and looks for matches based on severity, incident type, or team. If none match, the default retrospective process is used.
Yes. By default, responders can skip a retrospective unless it is mandatory for that incident. Retrospectives can also be auto-skipped based on configured rules, and auto-skipped retrospectives can be resumed later if needed.
Processes determine which retrospective flow applies to an incident. Steps define the tasks responders complete as part of that flow. Templates define the structure and content of the retrospective document itself.
Some older workflows, variables, integrations, or task names may still use the older postmortem terminology. Rootly continues to support these references for backward compatibility, but new documentation and configuration should use retrospective terminology.