Skip to main content

​
How Duplicate Incidents Work

During fast-moving operational issues, teams may accidentally create multiple incidents describing the same underlying problem. Rootly allows you to mark one incident as the duplicate of another, ensuring responders align around a single source of truth. When an incident is marked as a duplicate:
  • The duplicate incident is linked to a canonical (primary) incident
  • The duplicate’s timeline records the change
  • Workflows, alerts, and Slack channels can consolidate under the primary incident
  • Optionally, the duplicate incident can be automatically cancelled
This helps reduce fragmentation, avoid duplicate work, and maintain accurate historical records.
Duplicate incidents use a dedicated field (duplicate_incident_id) and are not the same as sub-incidents, which use parent_incident_id.

​
Why Mark Incidents as Duplicate

Teams benefit from merging duplicates because it:
  • Ensures responders focus on the correct incident
  • Reduces conflicting updates or duplicated communication
  • Clarifies ownership and priority
  • Simplifies retrospectives and reporting
  • Maintains a clean incident list without losing context
Typical scenarios include:
  • Multiple teams declare the same outage simultaneously
  • Monitoring tools trigger multiple detection paths
  • Slack responders create overlapping incidents during triage

​
What Happens When You Mark an Incident as Duplicate

When you mark Incident A as a duplicate of Incident B:
  • Incident A becomes linked to Incident B
  • A timeline entry is added to Incident A
  • Slack responders receive a confirmation message
  • (Optional) Incident A is automatically cancelled and any attached alerts are resolved
  • The “Duplicate of …” banner appears in the duplicate incident UI
This ensures full transparency on how and why incidents were consolidated.
Auto-cancellation is enabled by default when marking a duplicate but can be turned off during the action.

​
Where You Can Manage Duplicates

​
In the Web Interface

From an incident, open the action menu and select Mark as Duplicate.
You can then:
  • Search for the canonical incident
  • Choose whether to auto-cancel the duplicate
  • Add a cancellation reason for context
A redirect takes you to the canonical incident after completion. Learn how to mark duplicates via Web →

​
In Slack

Use one of the supported commands:
  • /rootly dup
  • /rootly duplicate
This opens a modal where you can:
  • Select the canonical incident
  • Provide a cancellation reason
  • Enable/disable auto-cancel
Slack posts a confirmation message to the duplicate’s channel when completed.
Duplicate marking is not available for scheduled maintenance incidents.
Learn how to mark duplicates via Slack →

​
API Support

You can also mark incidents as duplicates programmatically using: 
POST /api/v1/incidents/:id/duplicate
Supported attributes include:
  • duplicate_incident_id
  • auto_cancel_incident
  • reason_for_cancellation
Rootly updates the relationship and adds a timeline entry automatically.
API duplicate linking does not automatically resolve attached alerts—this behavior is only available via Slack or Web.

​
Best Practices

  • Always consolidate early
    Merge duplicate incidents as soon as duplication is detected to reduce confusion.
  • Use auto-cancel thoughtfully
    Cancelling duplicates keeps your incident list clean, but you may leave them open temporarily during complex triage.
  • Write clear cancellation reasons
    Adds helpful context for retrospectives and audit history.
  • Educate responders on Slack commands
    Many duplicates are resolved faster when responders use /rootly dup.
  • Review duplicate patterns
    Repeated duplicates may highlight monitoring or workflow tuning opportunities.

​
FAQ

Duplicate incidents refer to the same problem, while sub-incidents represent related but distinct workstreams.
Yes. Edit the incident to remove the duplicate relationship and update the status.
Yes, but only if you have permission to view the target incident.
Any responder with update permission on the incident (including private-incident permissions when relevant).
No. Timelines remain separate, but all future response activity should occur in the canonical incident.