> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rootly.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Marking Incidents as Duplicate
> Mark incidents as duplicates in Rootly to consolidate response efforts via the web UI, Slack, or API, with auto-cancellation support and parent linking.
## 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 →](/incidents/incident-operations/web-marking-as-duplicate)
***
### **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 →](/incidents/incident-operations/slack-marking-as-duplicate)
***
## API Support
You can also mark incidents as duplicates programmatically using:
```http theme={null}
POST /api/v1/incidents/:id/duplicate
```
Supported attributes:
The canonical incident this incident is a duplicate of.
When true, the duplicate is automatically cancelled after linking. Enabled by default — matches the Web and Slack flows.
Free-text context recorded on the cancellation — helpful for retrospectives and audit trails.
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.
***
## Frequently Asked Questions
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.
***
## Related Pages
The adjacent operation — split into sub-incidents instead of consolidating.
The umbrella page covering how incidents work end-to-end.
What happens to lifecycle state when an incident is marked as a duplicate.