Skip to main content

​
How It Works

You can create a sub-incident directly from an existing incident in the Rootly web interface.
This is useful when multiple teams need to investigate different parts of a larger incident while keeping everything linked and coordinated.

​
Create the Sub-Incident

1

Open the Sub-Incident Action

In any parent incident, click the ⋯ (More) menu next to the incident title or status. You will see Create Sub-Incident when:
  • The incident is not already a sub-incident
  • The incident is not a scheduled maintenance incident
  • You have permission to create incidents
2

Complete the Sub-Incident Form

Selecting Create Sub-Incident opens the standard New Incident form. Rootly automatically injects a hidden parent_incident_id, ensuring the new incident is created as a sub-incident.You can customize:
  • Summary
  • Severity
  • Impacted services & functionalities
  • Roles, assignees, and metadata
  • Any fields defined in Settings → Fields
Click Create Incident to finish.

​
What Happens After Creation

Once saved:
  • The new incident becomes a sub-incident of the parent
  • Its kind is automatically derived (for example, normal_sub, scheduled_sub)
  • The parent incident displays a Sub-Incidents panel linking to all sub-incidents
Sub-incidents cannot themselves create further sub-incidents.
They represent the lowest level in an incident hierarchy.

​
Optional: Attach an Existing Incident as a Sub-Incident

If you already have an incident you want to convert into a sub-incident:
1

Open the Child Incident

Open the child incident you want to attach.
2

Open the Attach Action

Go to ⋯ → Attach to Parent Incident.
3

Choose the Parent

Choose a parent incident from the autocomplete search.
4

Save

Save to attach the child to the parent.
This option appears only when:
  • The incident is not already a sub-incident
  • It has no sub-incidents of its own
  • You have permission to create incidents
The parent list only shows incidents of the same kind as the one you’re attaching. To attach from the incident’s Slack channel instead, see attaching an existing incident in Slack.

​
Best Practices

  • Use sub-incidents when multiple teams or domains are involved
    Helps isolate workstreams while maintaining a unified parent incident.
  • Keep naming clear and scoped
    Example: “Database Failover Sub-Incident (SRE)” or “Authentication Latency (Identity Team)”.
  • Enable workflows
    Many teams auto-assign roles, create tasks, or spin up Slack channels for sub-incidents.
  • Avoid unnecessary sub-incidents
    If the effort is small or tightly scoped, keep work in the main incident.
  • Review sub-incidents together during retrospectives
    They provide excellent insight into how different teams contributed to resolution.

​
Troubleshooting

This usually occurs when:
  • The incident is already a sub-incident
  • The incident is a scheduled maintenance incident
  • You lack create incident permissions
  • Your team has feature restrictions
This happens if:
  • The incident already has a parent
  • It has its own sub-incidents (nested sub-incidents are not allowed)
  • The parent is a different kind of incident, for example a scheduled maintenance parent for a normal incident
  • You don’t have adequate permissions
Inheritance varies depending on:
  • Workflow automation
  • Feature flags (for example, parent/sub synchronization)
  • Privacy rules
  • Origin of creation (Slack vs Web)
Timeline sync requires:
  • enable_parent_and_sub_incident_sync feature flag
  • parent_to_sub_incident_sync enabled on the incident
    Only non-internal timeline events sync across related incidents.