Major incidents
Some incidents are bigger than one commander can carry: everything is down, many people call at once, management wants to know every half hour. A major incident is an incident with more around it:
- a manager, a communications lead and a technical lead beside the commander;
- a procedure to follow;
- escalation when nobody takes it or the updates stop;
- internal updates to stakeholders on a rhythm;
- a post-incident review that is required, owned and followed up.
Incident → Major incident → Resolved → Review required → Review complete
Major incident → Incident: Stand down major incident; it stays an incident
Review required → Review overdue: past its due date (five days by default)
Major incidents come with the Major Incident Management plugin, which needs Incident Management. If you don't see Major Incident Management under Plugins in the sidebar, an admin turns it on under Settings → Plugins.
Who can use it
Needs the Major Incident Management plugin, built on Incident Management.
| Who | Can |
|---|---|
| Incident Manager | Declare and stand down major incidents, run them, and change the settings. |
| Incident Responder | Run major incidents: roles, the bridge, the procedure checklist, stakeholder updates and child incidents. |
| Anyone who can see the incident | See the major incident and its review. |
| Administrator | Everything. |
Each permission in detail: Settings.
Declaring a major incident
| How | Where |
|---|---|
| On an incident | … at the top right → Declare major incident…. |
| From scratch | Declare major incident on the Major Incident Management page declares the incident and makes it major in one go. |
| By itself | Your admin can make incidents of some priorities (P1, say) major as soon as they are declared or raised to that priority. The timeline says so. |
Give a reason in a sentence (it goes in the email), and the roles and the bridge if you know them already. Declaring starts the procedure and emails the stakeholders and anyone you gave a role.
[!NOTE] The commander stays in charge of the incident itself.
Stand down major incident… (same menu) takes it back: it stays an incident, and its roles, procedure and stakeholder updates go. The timeline keeps what happened.
On the incident page
A major incident gets a red banner under the status steps: when it became major, the manager, the bridge (a link you can click), when the next stakeholder update is due, and Escalated when it was. The incident list shows a Major badge. A Major incident tab has the rest.
Roles
| Role | Does |
|---|---|
| Major incident manager | Runs the response as a whole: procedure, escalation, people. |
| Communications lead | Writes the updates, to stakeholders and requesters. |
| Technical lead | Leads finding the cause and the fix. |
Like the commander, each must be able to see every affected unit. A new role holder gets an email.
Bridge
Where the response meets: a call or chat link, or a room.
Procedure
The checklist from your settings, like "Open a bridge", "Send the first customer update", "Notify management", each for a role and due some minutes after declaring. Check a step off when it's done; the desk keeps who and when, and marks steps that are late. Add a step for anything this incident needs.
Stakeholders
People inside the company who hear how it goes: management, account managers. They start from your settings; add or remove people per incident.
Send update (also on the banner) emails them a short update in plain text: what is affected, what is being done, when the next update comes. They get the whole update in the email, even those who can't open the incident. Updates are due every hour (or what you pick); when one is due, the communications lead (or the manager) is reminded.
[!IMPORTANT] Stakeholder updates are separate from Send update on the incident, which goes to the requesters of the linked cases (and the status page).
Child incidents
A major incident can have child incidents: incidents that are part of it, each with its own linked cases, such as "Card payments fail" and "Refunds delayed" under "Payment provider outage". Add them under Child incidents in the Major incident tab, and take them out with the bin.
[!NOTE] An incident has one parent at most, in the same organization. A major incident can't be a child, and a child can't have children of its own.
With Update child incidents from the major incident on in the settings, an update you send to the major incident's requesters also goes to the requesters of each open child incident, and onto their timelines ("from INC-12"). Turn Send updates to the child incidents' requesters too off on one major incident to keep its updates to itself.
Escalation
While a major incident is open, the desk checks every minute for:
| Trigger | After (by default) |
|---|---|
| No commander since it became major | 15 minutes |
| No update: a note, an update to requesters or a stakeholder update | 30 minutes |
When one fires:
- The desk emails the first escalation level your admin set up (people, or everyone placed in a unit; only those who can see the incident), and puts it on the timeline.
- If it goes on, it emails the next level every 15 minutes (or what is set), staying at the last.
- When someone takes it and updates flow again, the next escalation starts over at the first level.
Post-incident reviews
A post-incident review (often called a post-mortem) looks at what happened and what will change.
[!IMPORTANT] Once a major incident is resolved, a review is required: it gets an owner (the manager, else the commander) and a due date (five days by default), and the owner gets an email.
Your admin can require reviews for other priorities too (P1 and P2 incidents that weren't major). On the incident's Review tab, under the review:
- Owner and Due can be changed.
- Write the review above as usual: it starts from your organization's major incident template, with the facts, the cause, Insert timeline and the summary for customers like any incident review. Then Mark the review complete.
- Actions: what the review decided to change, each with an owner and a date. Check them off when done. With Software Development on, Dev task makes one a task in a project you can add tasks to; it is done when the task is.
Reviews past their due date are overdue: the owner gets an email, the incident and the list show Review overdue, and they count on Reports.
The Major Incident Management page
Major Incident Management in the sidebar (the number is open major incidents and overdue reviews) has two lists:
- Major incidents: the open ones, in the same list as the Incidents page with the same search, filters (the Service one too), chips, sorting and pages (Status → Any status or Resolved and closed for the finished ones). Its default columns are the status, the manager, the requester and account, how far the procedure is, when the next stakeholder update is due, and when it was declared; Columns adds the commander, the escalation level and everything an incident has. This list keeps its own column choice.
- Reviews: every required review you can see, overdue first, with its owner, due date and actions. Search (a key, a title or a person's name) narrows it, with 25, 50, 100 or 500 rows a page.
You see a major incident when you can see the incident.
Settings
| To | Permission | Held by |
|---|---|---|
| Declare and stand down a major incident | Declare major incidents (incident.major.declare) | Incident Manager |
| Work on one: roles, the procedure, stakeholder updates, child incidents | Run major incidents (incident.major.write) | Incident Manager, Incident Responder |
| Change Settings → Major Incident Management | Major incident settings (incident.major.settings) | Incident Manager |
Priorities that are major by themselves still declare it.
The settings have, per organization:
| Section | What it sets |
|---|---|
| Declaring and reviews | The priorities that are major by themselves; the priorities that need a review even when not major; how many days a review is due after resolving; the review template; and Update child incidents from the major incident (see Child incidents). |
| Procedure | The checklist new major incidents start with: each step's role and how many minutes after declaring it is due. Changes apply to new major incidents. |
| Escalation and stakeholders | When to escalate (no commander after, no update for, then again every), the levels (people and units), the default stakeholders and how often an update is due. |
Reports
Reports → Major Incident Management shows:
- how many became major (and how many by their priority);
- how long it took to declare them and to resolve them;
- how many were escalated;
- how much of the procedure was done on time;
- stakeholder updates sent;
- reviews completed (on time) and overdue;
- the actions from reviews (and how many became dev tasks).
For AI assistants and the API
With the plugin on, tokens can get major:read, major:write and major:admin. AI assistants get tools to list and
read major incidents and reviews, declare and stand down, assign roles, check off steps, send stakeholder updates,
manage reviews and their actions (making dev tasks with dev:write), and the numbers. The API is described in
building a plugin.