Major Incident Management: Running the War Room When Everything Is on Fire

When a hundred tickets are really one incident

There is a moment every support team recognizes: the queue explodes, and every new ticket is a variation on the same theme — logins failing, the app timing out, checkout broken. Agents instinctively do what they always do, which is pick up tickets and start replying individually. That instinct, which is exactly right for normal work, is exactly wrong here. You do not have a hundred problems. You have one problem being reported a hundred times, and answering each ticket separately means a hundred agents-worth of effort, a hundred slightly-different answers, and no one actually driving the fix.

A major incident is an event with high impact and urgency that overwhelms your normal handling — a widespread outage, a security event, a broken critical path. Major incident management (MIM) is the deliberate practice of recognizing that moment and switching into a different mode: coordinated, centralized, and communicated. It is not the same as your everyday incident vs problem handling, and it is more than the customer messaging in incident communication for support. MIM is the command structure that sits over both while the fire is burning.

Declare it — the switch that changes everything

The single most important MIM skill is declaring a major incident early. Teams routinely lose the first thirty minutes because no one wanted to hit the alarm, and by the time someone does, the damage and the confusion have compounded. Make declaring cheap and blameless: a clear trigger (a spike in same-cause tickets, a critical service down, a severity-1 by your priority-vs-severity definition) and anyone senior enough to pull it. A false alarm costs a few minutes; a late declaration costs the whole first hour.

Declaring does three things at once. It tells the team to stop working the symptoms individually. It summons the right people into one place. And it starts the clock and the record that you will need afterward.

One coordinator, and what they actually do

The heart of MIM is a single incident coordinator (often called an incident commander) whose job is emphatically not to fix the technical problem. Their job is to run the response so the people who can fix it are free to do so. That distinction is what separates a controlled response from a chaotic one. The coordinator:

• Owns the war room. One channel — a dedicated chat, a bridge call, or both — where everyone working the incident is present and status is visible. No side conversations, no parallel threads. If it matters, it happens here.
• Assigns roles, not tasks. Someone owns the technical investigation, someone owns customer communications, someone owns internal updates. The coordinator makes sure each seat is filled and stays out of the weeds themselves.
• Runs a heartbeat. Regular, time-boxed updates ("next update in 15 minutes") even when the update is "no change." Silence during an incident breeds a second incident made of anxiety and duplicate questions.
• Protects the responders. Executives and anxious stakeholders get their answers from the coordinator, not by DMing the engineer mid-fix. Shielding the people doing the work is a real and underrated part of the role.

Support's job during the fire

While engineering chases root cause, support has a distinct and vital workstream: be the single voice to customers so they are informed and the queue does not become a second disaster. The tactics that make this work:

• Post publicly and fast. A public status page with a plain acknowledgment ("we are aware, we are investigating, next update at…") deflects an enormous share of inbound before it is ever filed. It is the highest-leverage move support can make in the first five minutes.
• Consolidate the duplicates. Merge and link the flood of same-cause tickets to the incident rather than answering each in isolation. One canonical update, propagated, beats a hundred hand-typed replies.
• Use one approved message. The coordinator and support agree on the wording; every agent uses it. Freelancing the message during an incident is how you end up with three contradictory answers screenshotted side by side on social media.

After the fire: the review that pays it back

A major incident is not over when service is restored. The last, non-optional step is a blameless post-incident review: a factual timeline, what actually caused it, what slowed the response, and the specific follow-ups that make the next one shorter. The review is where a major incident converts from pure cost into durable improvement, and it is the on-ramp to the longer-term problem management work of killing the root cause for good. Capture the timeline while memories are fresh, feed the follow-ups back into your runbooks and playbooks, and the next time the queue explodes, you will recognize the moment faster and run the room better. See how the tooling supports this on the features page.