Skip to main content
Marking an incident as a duplicate helps consolidate response efforts when multiple responders report the same issue. The Web UI provides a simple modal to link the current incident to its canonical incident and optionally auto-cancel it.
Duplicate incidents use a dedicated duplicate_incident_id relationship and are separate from sub-incidents, which use parent_incident_id.

​
Mark a Duplicate via the Web UI

1

Step 1 — Open the duplicate dialog

In the top-right corner of the incident page, click the ⋯ menu and select Mark as Duplicate.
Open the Mark as Duplicate action
This option appears only when the incident is not already a duplicate and you have permission to update the incident.
2

Step 2 — Choose the original incident

In the modal, search for and select the original (canonical) incident.
This is the incident the current one will be linked to.You can also:
  • Auto-cancel the duplicate (enabled by default)
  • Provide a reason for cancellation, which appears in the timeline
Duplicate modal with incident selector and auto-cancel toggle
3

Step 3 — Confirm the action

Click Confirm to save your changes.Rootly will:
  • Link the incident as a duplicate
  • Add a timeline entry
  • Post a notification to the duplicate’s Slack channel (if Slack is connected)
  • Cancel the duplicate (if enabled)
  • Redirect you to the original incident

​
What Happens After Marking a Duplicate

  • The duplicate incident displays “Duplicate of …” at the top of the page
  • A non-editable timeline entry records who performed the action and why
  • Auto-cancel will:
    • Move the incident to Cancelled
    • Resolve all attached alerts automatically
  • Slack responders are notified if the Slack integration is active
Auto-cancel is recommended to reduce noise in reports and Slack channels, but you may disable it when the duplicate incident still contains useful investigation context.

​
Best Practices

  • Use “Mark as Duplicate” early
    Consolidating incidents right away helps reduce confusion across teams and channels.
  • Always designate a canonical incident
    The canonical incident should contain the most accurate timeline and central communication thread.
  • Provide a clear cancellation reason
    This helps responders understand why context moved and ensures retrospectives remain accurate.
  • Auto-cancel duplicate incidents when appropriate
    This prevents “ghost incidents” from appearing unresolved in dashboards or workflow triggers.
  • Avoid marking scheduled maintenance incidents as duplicates
    Maintenance windows follow different lifecycle logic and should remain separate.
  • Review duplicate frequency
    Frequent duplicates may indicate alerting issues, unclear runbooks, or multiple teams raising incidents for the same symptom.

​
Troubleshooting

  • You may not have update permission for the incident.
  • The incident may already be marked as a duplicate.
  • Scheduled maintenance incidents cannot be marked as duplicates.
  • The incident you’re looking for may be private and you may not have permission to view it.
  • The selector excludes the current incident automatically.
  • Try searching by title or ID.
  • The auto-cancel toggle may have been turned off.
  • The incident may have already been cancelled.
  • Workflow restrictions or permissions may prevent auto-cancel in rare cases.
  • Slack may not be integrated for your team.
  • The duplicate incident may not have a Slack channel.
  • Notification settings may restrict posting confirmations.
Auto-cancel removes the duplicate from most active incident metrics.
If auto-cancel was disabled, manually cancel or close the duplicate to prevent clutter.