Major incidents

Declare an incident a major incident, keep a war-room and stakeholder log, and write the post-incident review.

Incident ticket → Declare Major Incident

A major incident is an incident serious enough to run differently: an outage, a breach, anything affecting many people at once. Declaring one raises its priority to the top. It also tells people and gives the incident a timeline log and a post-incident review. You can tell your requesters (your workspace may call them customers or employees) what is happening through the public status page.

Declare a major incident

Open the incident. Only incidents can be declared; other ticket types do not show the button.
Choose Declare Major Incident, next to the ticket's status and priority.

When you declare it:

the priority is raised to the highest level, and on plans that include SLA Management the SLA targets are recalculated for that priority;
the ticket shows a Major Incident badge with the time it was declared, and the declaration is written in its history;
a message is posted to your workspace's Slack or Teams channels, if any are set up in notification channels;
whoever is on call for the ticket's project gets a notification, unless they declared it themselves.

Declaring is permanent: there is no way to undeclare a major incident. It stays active until the ticket itself is resolved through its normal workflow.

How it differs from a normal incident

It is still the same ticket, with the same workflow, assignee and comments. What changes is how visible it is and what you can record on it:

Home shows a banner listing every active major incident at the top of the page.
Dashboards can carry a Major incidents widget.
In Tickets, More filters → Major incidents only narrows the list to them.
The ticket gains a Major Incident log, and once it is resolved, a post-incident review.
If your workspace's status page is on, the incident appears there.

Keep the log

The Major Incident log section shows who is on call for the project first, then the timeline. To add an entry:

Pick the entry type: War room for internal bridge updates (what is happening, who is on it), or Stakeholder comms for updates meant for the people affected.
Write the update and choose Log.

Entries show their author and time. They cannot be edited or deleted afterwards.

Updates for stakeholders

A Stakeholder comms entry is published to your public status page and emailed to everyone who has subscribed to it and confirmed their address. Before it goes out, you are asked to confirm with Publish update.

The status page lists major incidents that are still open, or were resolved in the last 7 days. It shows each one's key and title and its stakeholder updates, oldest first.
War room entries are never published, and neither are the names of the people who wrote the updates.
When the status page is turned off, stakeholder entries are only kept in the log; nothing is published or emailed.

A published update cannot be edited or withdrawn. Read it twice before you choose Publish update.

Write the post-incident review

Resolve the incident. Until then, the log says Resolve this incident to generate its Post-Incident Review.
Choose Generate Post-Incident Review at the foot of the log.
Choose View draft to open it.

The review is a draft, internal document in Docs, titled "Postmortem:" plus the incident's title and key, and linked to the ticket. It has these sections: Summary (from the incident's description), Impact, Timeline (every log entry with its time in UTC, its type and its author), Root cause, Resolution, and Action items. Each incident gets one review; after that, edit and publish it like any other document.