Creating Sub-Incidents

Learn how to split large incidents into sub-incidents for better organization across multiple teams, with workflow automation support.

Overview

For larger or cross-functional incidents, you may want to break work into sub-incidents.
A sub-incident allows a team to investigate, coordinate, and track their scope independently—while maintaining shared context with the parent incident.

Each parent incident can have multiple sub-incidents.

---

What Is a Sub-Incident?

A sub-incident is a normal incident that is linked to a parent using parent_incident_id.
Rootly automatically assigns the sub-incident a kind based on its parent:

• normal_sub
• test_sub
• scheduled_sub

Sub-incidents are not the same as duplicate incidents.
Duplicates link via duplicate_incident_id and do not form a hierarchy.

---

Restrictions

• Sub-incidents cannot be split further (no nested sub-incidents).
• A sub-incident must have a parent incident.
• You cannot create a sub-incident from an existing sub-incident.
• Some UI options (like “Attach to Parent Incident”) only appear when:
  • The incident is not already a sub-incident
  • It has no existing sub-incidents
  • You have permission to create incidents

---

Creating Sub-Incidents

Rootly supports creating sub-incidents through two interfaces:

1. Slack – Use commands such as /rootly sub, /rootly split, /rootly fork, or /rootly swimlane
   → See the Slack guide →
2. Web – Use Create Sub-Incident or Attach to Parent Incident from the incident menu
   → See the Web guide →

---

Slack Creation

Use any of the following commands in the parent incident’s Slack channel:

/rootly split
/rootly sub
/rootly fork
/rootly swimlane

This opens the Create Sub-Incident modal, already linked to the parent.

Slack enforces:

• You must be in an incident channel
• The parent cannot itself be a sub-incident
• You must have permission to create incidents

Slack-created sub-incidents use the same logic as Web-created sub-incidents, including workflow triggers and automatic Slack-channel creation (when enabled).

---

Web Creation

From the parent incident:

• Click … → Create Sub-Incident, or
• Use Attach to Parent Incident to convert an existing incident into a sub-incident

When attaching an existing incident, Rootly updates its kind and sets its parent relationship.

---

What Gets Inherited?

Depending on your configuration, sub-incidents may inherit:

• Severity
• Status
• Privacy settings
• Incident types
• Attached services, functionalities, environments
• Teams / groups
• Jira epic or Google Drive folder links
• Slack channel creation settings
• Parent → sub or sub → parent timeline syncing (feature-flag dependent)

When timeline syncing is enabled, updates may automatically propagate between related incidents—excluding internal-only events.

---

Configuring Workflows for Sub-Incidents

Sub-incidents are fully compatible with Rootly Workflows.

To target sub-incidents, set a workflow condition such as:

Kind → is one of → normal_sub, test_sub, scheduled_sub

Use cases include:

• Creating role assignments for sub-incident teams
• Syncing updates to the parent incident
• Auto-generating investigative tasks
• Auto-creating a Slack channel for each sub-incident

---

Best Practices

• Use sub-incidents to delegate ownership to teams like SRE, Security, or Networking.
• Keep the parent incident customer-facing, using sub-incidents to track internal workstreams.
• Use workflows to create structure, such as templated tasks, roles, or Slack-channel creation.
  • Use the Create a sub incident Workflow Action to automatically create a sub-incident for specific scenarios, like being able to coordinate with stakeholders outside of your engineering response teams. See this in action here.
• Avoid unnecessary splitting—small tasks can often stay in the parent incident.
• Name sub-incidents cleanly and consistently, reflecting the scope of work.

---

Troubleshooting

I don’t see the option to create a sub-incident

This occurs when:

• The incident is already a sub-incident
• It has its own sub-incidents
• You do not have permission to create incidents

Slack says the incident cannot be split

Slack prevents splitting when:

• You are not in an incident channel
• The incident is a sub-incident
• You lack required permissions

My sub-incident didn’t inherit fields

Inheritance depends on:

• Feature flags (parent/sub sync)
• Workflows that override defaults
• Creation method (Slack vs Web)
• Privacy restrictions

Timeline updates are not syncing

Parent and sub-incident timeline syncing must be enabled for your account. Once it is:

• The incidents must be linked as parent and sub-incident.
• Only non-internal timeline events sync. Events marked internal stay on the incident where they were added.

If updates still do not sync after confirming both, contact Rootly support to check that syncing is enabled for your account.

Unable to attach an existing incident as a sub-incident

This happens when:

• The incident is already a sub-incident
• It has existing sub-incidents
• It is a scheduled maintenance incident
• Permissions prevent linking

How do I track the same issue recurring over time?

Sub-incidents group parallel workstreams of one active event, and marking as duplicate links two records of the same event. For a failure that keeps coming back across separate incidents, tag the incidents instead:

1. Pick a marker: an incident Type, a Cause, or a custom field, or a combination.
2. Set it on each incident during the response or in the retrospective.
3. Filter the incidents list by that marker to see the full set of matching incidents in one view.
4. To analyze the set — recurrence, severity, time to resolve — add a custom dashboard panel with a panel-level filter on the same marker. Dashboard-level filters cover date range, period, team, and service; Type, Cause, and custom fields are configured per panel.

You can also pull the tagged set through the API to analyze recurring themes externally.