> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ravenna.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Incidents

> Group related tickets under an incident tracker in Ravenna so status, priority, and public updates flow to every affected requester from one place.

Use an incident tracker when many requesters report the same problem, such as an outage. You link each affected ticket to one tracker ticket and work the incident there. Status and priority changes on the tracker flow to every open linked ticket. You can also broadcast a public reply to every linked requester at once.

## Mental model

An incident tracker is an ordinary ticket flagged as an incident. Other tickets point at it through an incident link. Linked tickets stay open and keep their own requester, messages, and channel threads. The tracker drives updates to them.

| Operation | What happens | Use when |
| - | - | - |
| **Incident** | Linked tickets stay open. Tracker status, priority, and public replies propagate to open linked tickets. | Many requesters are affected by the same issue |
| **Merge** | Source closes and points at a primary. Reversible via unmerge. | Multiple tickets describe the same request |
| **Parent/sub-ticket** | Tickets stay independent, linked hierarchically. No status propagation. | Breaking work into separately tracked pieces |

***

## Creating and linking

* **Create incident** (row action, detail action, or bulk action) opens the create modal in incident mode, seeded with the selected tickets as related tickets. The modal locks the workspace and disables bulk creation.
* A tracker's priority defaults to the highest priority among the linked tickets when none is given (Urgent > High > Medium > Low > No priority).
* A ticket becomes a tracker when created as one or the first time something is linked to it.
* Trackers created through **Create incident** have no form. The incident create input ignores `requestTypeId` and `customFields` if you send them, the form picker is disabled, and the workspace's default form is not applied. You can't attach a form to a tracker later.
* **Link to incident** links a ticket to an existing tracker. **Unlink from incident** returns it to a standalone open ticket.
* The **Create incident** and **Link to incident** actions only appear on tickets that are not trackers, not linked, and not merged. **Unlink from incident** only appears on linked tickets.
* Link and unlink operations require permission to modify tickets and are recorded as incident linked/unlinked events.

**Validation rules:**

* A ticket already linked to another incident is rejected (`TICKET_INCIDENT_ALREADY_LINKED`) unless the user confirms the move. The web app prompts "Move to this incident?"
* A tracker cannot be linked to another incident (`TICKET_INCIDENT_NESTED`). A linked ticket cannot act as a tracker.
* Merged source tickets cannot be linked (`TICKET_INCIDENT_MERGED_SOURCE`). A merged ticket cannot be a tracker (`TICKET_INCIDENT_TRACKER_MERGED`).
* Linking with no tickets fails with `TICKET_INCIDENT_NO_TICKETS`.
* Attaching, swapping, clearing, or editing the form or form field values on a tracker is rejected (`TICKET_INCIDENT_FORM_LOCKED`). This applies to single updates, bulk updates, and form submissions.

***

## Cascade and broadcast

* A status or priority change on a tracker is queued and applied to each open linked ticket, skipping tickets that already have the value. It runs for every source (web, Slack, workflows, MCP). Changes on linked tickets never cascade back.
* The cascade reads the tracker's current value at processing time, so a delayed retry never applies a stale value.
* For linked tickets in another workspace, Ravenna applies the status with the same name in that workspace. The ticket is left unchanged when no match exists.
* The tracker's message box shows a **Send to all linked tickets** checkbox, on by default (`TicketActionDock.tsx`). When checked on a public reply, Ravenna creates a real copy of the message on each open linked ticket, so each requester is notified through their own channel.
* Private notes are never broadcast (`TICKET_INCIDENT_PRIVATE_BROADCAST`).

***

## Constraints and gotchas

* One incident per ticket. Moving a ticket to a new incident removes it from the old one.
* Only status and priority cascade. Assignee, tags, and other fields do not.
* Closed linked tickets receive neither cascades nor broadcasts.
* Broadcast is on by default for each public reply on the tracker. Clear the checkbox to keep a reply on the tracker only.
* Trackers never take a new form. A ticket promoted to a tracker by its first link keeps its existing form and field values, but they become read-only.


## Related topics

- [Incident intake](/guides/playbooks/security/incident-intake.md)
- [Link tickets to an incident tracker](/api/ticket/link-tickets-to-an-incident-tracker.md)
- [Unlink tickets from their incident tracker](/api/ticket/unlink-tickets-from-their-incident-tracker.md)
- [Create an incident tracker and link tickets to it](/api/ticket/create-an-incident-tracker-and-link-tickets-to-it.md)
- [Tasks](/documentation/tickets/tasks.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.