Skip to main content
Retrospectives are a critical part of a strong incident management practice. They create space for learning, help teams improve how they respond, and reinforce a culture of reliability over time. Not every incident needs the same level of follow-up, though, which is why Rootly is built to support a more flexible approach. Rootly helps you right-size the retrospective process by letting you define multiple retrospective processes and choose when each one should apply. You can tailor retrospectives based on factors like severity, incident type, or team, so each incident gets the level of follow-up it actually needs.
Rootly uses a default retrospective process as a fallback when no custom process matches an incident.
Each retrospective process includes its own ordered steps. These steps can be used to guide responders through common follow-up work such as gathering data, writing the retrospective document, hosting a review meeting, creating action items, and sharing the final report. Retrospectives can also be configured to be optional, mandatory, or skipped for specific teams, severities, or incident types. This gives organizations more control over when a full retrospective is required and helps reduce unnecessary process overhead for lower-impact incidents.
A retrospective process without any conditions is inactive and will not be used until conditions are added.
When an incident is created or updated, Rootly evaluates the configured conditions and selects the retrospective process that applies. If multiple custom processes match, Rootly uses the most recently created matching process. Once selected, the process steps are created on the incident and can include due dates, assignees, and notifications. When Custom Statuses are enabled, retrospective steps can also be organized by resolved phase, such as a retrospective phase and a follow-up phase. This makes it possible to right-size the process not just by incident context, but also by where the incident is in its post-resolution lifecycle. Learn more in the video below.

​
How It Works

Rootly uses retrospective processes to determine which follow-up steps should be created for an incident. A retrospective process can include:
  • Ordered steps
  • Due dates
  • Assignees based on incident roles
  • Required or skippable steps
  • Reminder notifications
Each process can be configured to apply based on:
  • Severity
  • Incident type
  • Team
If no custom process matches an incident, Rootly uses the default retrospective process.

​
Default Retrospective Process

Every workspace includes a default retrospective process. This process acts as the fallback when no other process matches the incident. The default process includes a best-practice set of steps, such as:
  • Gather and confirm data
  • Write the retrospective document
  • Host a retrospective meeting
  • Create follow-up action items
  • Share the finalized retrospective
You can customize these steps, reorder them, and create additional retrospective processes for different incident scenarios.

​
Frequently Asked Questions

A retrospective process is a named set of follow-up steps used after an incident. Each process can include its own step order, due dates, assignees, and notifications, which allows teams to standardize how they complete retrospective work.
Rootly evaluates the conditions attached to each retrospective process when an incident is created or updated. A process can match based on team, severity, or incident type. If more than one custom process matches, Rootly uses the most recently created matching process. If none match, the default retrospective process is used.
Yes. Rootly allows you to configure retrospective behavior based on incident context. Depending on your setup, a retrospective can be required, optional, or automatically skipped for certain teams, severities, or incident types.
A retrospective step can include a due date, a default assignee, reminder notifications, and whether the step is required or skippable. Steps can also be tied to specific incident roles so the right responder is assigned automatically.
A retrospective process without any conditions is inactive. Rootly will not use it until at least one condition is added, such as a team, severity, or incident type.
Yes. When Custom Statuses are enabled, retrospective steps can be grouped by resolved phase. This allows teams to separate work into stages such as retrospective review and follow-up actions.