Major incident: declaring one and running it

A major incident is not a worse version of an ordinary incident; it is a different mode of working. Normal handling optimises for getting one thing fixed by the person best placed to fix it. Major incident handling optimises for coordination — many people, partial information, external pressure — and switching between the two modes needs an explicit decision rather than a gradual realisation.

Defining the major incident threshold

• Impact that is wide rather than deep: many customers affected, or a service everybody depends on.
• Anything with a regulatory or contractual clock attached, which forces coordination regardless of technical severity.
• Loss of a critical function with no workaround, as distinct from degradation that people can work around.
• Anything requiring more than one team to fix at once, since that alone justifies the coordination overhead.
• Not «the loudest customer is affected», which is how a threshold stops meaning anything.

Who does what once it is declared

Three roles matter and the first is the one most often missing: somebody coordinating who is deliberately not fixing anything. Their job is to hold the timeline, decide what is being tried, and stop five people from restarting the same service independently. Second is communication — internal and external updates on a stated cadence, even when the update is that there is no news, because silence generates more inbound contact than bad news does. Third are the people actually working the problem, who should be shielded from everything except the question they are solving. In a small organisation one person can hold two of these; nobody can hold all three.

Declare early and stand down cheaply. The cost of declaring a major incident that turns out to be ordinary is half an hour of several people's attention; the cost of not declaring one is that coordination starts an hour late, when the situation is worse and everybody is already tired.

Standing it down

1. Say explicitly that it is over, to the same audiences that were told it had started.
2. Separate restoration from resolution — service is back is not the same as cause is fixed, and conflating them produces a repeat.
3. Record the timeline while people still remember it, ideally during rather than after.
4. Hand over any remaining work as normal tasks with owners rather than leaving it in the incident.
5. Hold the review within days, when memory is accurate and before the next thing displaces it.

Ettex Chat suits the coordination itself: one channel for the incident, created when it is declared, holding the timeline as it happens rather than reconstructed afterwards. What is learned belongs in the postmortem, and the process for ordinary incidents belongs in the response plan — the whole point of a declaration is that this is neither of those.