What Makes an Incident Major, and Who Gets to Say So

Tuesday, 10:40, at Meridian Parts. Tomas has three tickets in front of him that are plainly the same ticket. The order system is "really slow" for the warehouse and "not loading" for a sales rep. It is "down" for the dispatch supervisor, who has written the word in capitals. The server answers a ping. The web page loads, eventually. Tomas can see the login screen from his own desk, so it is not down, exactly, and he has been told not to panic the building over a slow page. The dispatch supervisor rings. "Is this a big one? Should I send the drivers out without the pick lists?" Tomas does not know whether it is a big one. Nobody at Meridian has ever written down what a big one is.

A major incident is an outage or failure that hurts the organisation badly enough that the desk stops working tickets one at a time. It runs one coordinated response instead: one owner, one ticket, one stream of updates, and other work set aside until it is over. The word "major" is not a measure of how broken the system is. It is a decision about how the desk is going to behave for the next hour. This article is part of our Major Incident Management for Small Teams series. It is written for desks of two to six people who will never have a dedicated incident manager and need one anyway.

It covers what an incident is and what turns one into a major one. Then come the three criteria, with the test for each: people affected, a business process stopped, and no workaround. Next are the things that look major and are not, and why major is a mode and not a severity label. Then it covers who on a small desk is allowed to declare and the ninety-second declaration test with a worked example. Next is how to write the criteria down so the next Tomas does not have to guess. A short war story and the major-incident criteria card to copy finish the article.

An Incident, and Then a Major One

An incident is anything that was working and now is not, or is working badly enough that someone cannot do their job the normal way. A password reset is a request; a login that fails for a working password is an incident. The difference between the four kinds of work a desk handles is laid out in The Four Work Types in Plain Words. The only part needed here is that an incident is a break. Most incidents are small: one person, one laptop, one printer, fixed by one technician inside the normal queue without anyone else noticing.

A major incident is a break that cannot be handled inside the normal queue. Handling it that way would mean two technicians fixing the same server from opposite ends while the phone rings. The queue is built for many small, unrelated jobs worked in parallel by whoever is free. A major incident is one large job that needs the opposite: one person on the fix, one person on the people, and everyone else out of the way. The label exists to switch the desk from the first way of working to the second.

That switch has a cost, and the cost is why the definition matters. Declaring pulls people off other tickets, puts a manager on notice, and starts a clock of updates that someone has to keep. Declare too easily and the word stops meaning anything; by the third "major" printer jam, nobody looks up. Declare too late and the one person who could fix the thing spends the first forty minutes answering "is it just me?" over their shoulder. Most desks manage to do both in the same year, usually in that order.

The Three Criteria

Three questions decide whether a break is major, and all three are about the organisation rather than the system. The first is how many people are affected. The second is whether a business process has stopped. The third is whether there is a workaround that holds. An incident that answers "many", "yes" and "no" is major. An incident that answers "one", "no" and "yes" is a ticket. The interesting ones are in between, and the test later in this article is for those.

People affected means a group, not an individual, however senior the individual. A whole team, a whole site, a whole shift, everyone who uses one system: these are groups. The managing director's laptop is one person, and it gets a fast ticket, not a declaration. Count the people who cannot work, not the people who have noticed. On a Tuesday at 10:40 the three tickets at Meridian came from three people, and the system served sixty. The sixty are the number.

A business process stopped means something the organisation exists to do has halted. You should be able to name it in plain words: taking orders, picking and dispatching, seeing patients, paying people, answering customer calls, invoicing. The technician's instinct is to name the system ("the order system is slow"); the criterion asks for the activity ("the warehouse cannot pick"). This is the question that most often changes a decision. A slow system that has stopped a process is major and a dead system that has stopped nothing is not. The file server being down at 03:00 on a Sunday is an incident. The same file server might be down at 09:00 on the last working day of the month, when finance closes the books from it. That is a different animal wearing the same error message.

No workaround means the people affected cannot do the work another way, or can only do it in a way that will collapse within the hour. A printer queue failing when there is a second printer down the corridor has a workaround. The order system failing when the warehouse can pick from printed lists for a morning has a workaround, and the desk should say so in its first message. A workaround that exists but that nobody has been told about does not count, which is why the first notice in a major incident always names one if there is one. A workaround, for the record, is any way of getting the work done that does not depend on the broken thing, and "wait" is not one.

The three criteria are weighed together rather than ticked off. Two out of three is the common threshold on a small desk. Many people and a stopped process, even with a shaky workaround, is major. Many people with a solid workaround is a loud ticket. One out of three is enough only when the process is one the organisation cannot pause at all. Your playbook should name which processes those are, because it is not the desk's job to guess on the day.

What Major Is Not

A major incident is not an important person's incident. The director whose e-mail is broken has a problem that deserves a quick fix, and the desk should give it one through the normal priority rules. Declaring a major incident for one person, whoever they are, teaches the desk that "major" means "loud". The next time a whole site is down and quiet, nobody will declare. Priority handles the director; the series on prioritization frameworks elsewhere in this library explains how.

A major incident is not a high-priority ticket. Priority is a rank on a single ticket that sets how fast the desk promises to respond and resolve it; the top rank is often called P1. The priority tiers and the promises that hang off them are designed in Priority Tiers That Are Realistic. A P1 is still a ticket, worked by one technician in the normal queue with a short clock. A major incident may contain a dozen P1 tickets, or one, or none that were labelled that way at the time. The relationship is that a major incident almost always produces P1 tickets, while a P1 ticket rarely means a major incident. One is a rank. The other is a mode.

A major incident is not many tickets about the same small thing. Twenty tickets about a printer are twenty people with a workaround, and the right response is one reply sent twenty times and a part ordered. Ticket count is a sign that something is wide, not that something is major. (It is also not a planned outage, however badly the announcement went.) And it is not a security event, which needs its own playbook with different first steps and different people. A security event may also be a major incident, in which case both playbooks run.

The case that catches most desks is slowness. Nothing is down, every check comes back green, and the technician has been told not to cause alarm over a slow page. Slowness is major by exactly the same test as an outage. Suppose the process has effectively stopped because nobody can get through a screen in less than a minute. The people are affected and the process has stopped. The fact that the server replies to a ping is not a criterion. A system that is up and unusable is down for every purpose that matters. The ping is talking to the wrong audience.

Major Is a Mode, Not a Severity

The useful way to hold the definition is that "major" describes what the desk does next, not how bad the thing is. When the word is said, four things change at once. One ticket becomes the incident ticket, and every related ticket is linked to it rather than worked on its own. One person becomes the lead, who decides and keeps the record, and one person becomes the fixer, who touches the system and nothing else. Updates go out on a fixed interval to everyone affected, whether or not there is news. And every other piece of work on the desk waits, with the queue told so.

Each of those four has its own article in this series, starting with Declaring an Incident and the First Fifteen Minutes, and none of them has to be designed on the day. The declaration is a switch with a known cost, and the criteria are the conditions under which paying it is cheaper than not. That framing also makes standing down easy: if the fix takes four minutes, you declare, you fix, you send the all-clear, and the whole thing cost one e-mail. Nobody is embarrassed by a short incident.

Who May Declare

On a small desk, anyone may propose and a named role declares. The proposing part is important. The first person to see the pattern is usually the most junior technician, because they are the one reading the new tickets. If they believe only the manager may say the word, they will wait for the manager. The declaring part is a role rather than a person. It might be the technician on duty as lead, whoever is senior on the desk that day, or, on a two-person desk, either of them. The rule should fit on one line and be written in the playbook, which Preparing Before the Big One builds.

Do not make the manager the only person who may declare. Managers are in meetings, on trains, and at lunch, and an incident that waits forty minutes for permission is forty minutes longer. The manager's role is to be told within the first fifteen minutes and to make the decisions only a manager can make. Those include sending staff home or calling a customer. If the manager wants a veto, give them one: they may stand an incident down. They do not get to hold the start.

A solo administrator declares to themselves and tells one other person. That sounds like a formality, and it is the most useful one in the solo playbook. Saying "I am treating this as a major incident" to your own manager changes what you will be asked for in the next hour (updates, not fixes-while-you-explain). The one line of solo-desk advice that applies here is that a person who cannot hand off anything should at least hand off the worrying.

When in doubt, declare, and set a rule for how long doubt is allowed to last. Five minutes is a good number. If after five minutes of looking you cannot say "this is a ticket" with a straight face, say the other thing and start the clock. The cost of a declaration that turns out to be small is one message and ten minutes. The cost of a ticket that turns out to be major is that the first forty minutes of the incident were run by nobody. There is no refund on those.

The Ninety-Second Declaration Test

The test is four questions answered out loud, in order, by the person who suspects. It is called ninety seconds because that is what it takes when the answers are known. The point of the criteria card at the end of this article is to make the answers known in advance. Question one: who cannot work right now, and roughly how many of them are there? Question two: which business process, in plain words, has stopped or slowed to the point of stopping? Question three: is there a workaround, and will it hold for an hour? Question four: is the process one that the playbook says we never pause? Two "bad" answers, or one on question four, and it is major.

Here is the test run on Meridian Parts at 10:42. Who cannot work: the warehouse pick team, eleven people, and the six dispatch staff who need pick lists. Sales can still take orders by phone and key them later, so sales is affected but working. Which process has stopped: picking and dispatching, which has a cut-off at 14:00 for the day's courier collection. Is there a workaround: the warehouse can pick from yesterday's printed lists for the orders it already has, which covers about an hour. But nothing placed since 09:30 has a list at all. Is it a never-pause process: the playbook says dispatch cut-off days are, and every weekday is a cut-off day. That is three bad answers out of four, and the fact that the server pings was not among the questions. Tomas declared at 10:43, and the dispatch supervisor got the first notice at 10:46 with the printed-list workaround in it.

Notice what the test did not ask. It did not ask whether the technician was sure of the cause, whether the manager was available, whether it would look like an overreaction, or how many tickets had been logged. Those are the questions people actually ask themselves at 10:42, and none of them is a criterion. The test is deliberately short so that there is no room for them.

The table below runs the same four questions over situations that come up on most desks. That way, the shape of a "yes" and a "no" is familiar before the real one arrives. The verdict column is not a law; your never-pause list can move any row. Notice that the server's state appears in none of the columns that decide.

Two rows deserve a second look. The Sunday file server teaches that time of day is part of the people-affected question. The number of people who cannot work is zero until the building opens. And the branch internet link shows a verdict that depends on a workaround holding. The right move is a top-priority ticket with a note in it saying "becomes major if the terminals lose signal". The person who picks it up at 14:00 then knows the threshold without re-deriving it.

Writing the Criteria Down

The criteria are only useful if they exist before the incident, in a place the most junior technician will look, in words they can read while the phone is ringing. That is a card, not a policy. It is one page, pinned where the desk sits and copied into the top of the incident playbook. It has the three questions, the never-pause processes named, the one-line rule for who may declare, and the five-minute doubt rule. The template at the end of this article is that card. Eleven pages of policy on the intranet is also a place to put the criteria, in the sense that a lake is a place to put your keys.

Fill it in with the business, not from the server room. The never-pause list in particular has to come from the people who run the processes. Ask the warehouse manager what stops the building. Ask finance which days they cannot lose. Ask the clinic which screen they cannot see patients without. You will get a shorter list than you expect, and a more specific one. It will include something you had never thought of (the badge system that unlocks the loading bay, at Meridian). The desk owns the card. The business owns the list on it.

Review the card after every incident, declared or not, and especially after the ones that were not declared and should have been. The review in Closing the Incident and the Review has a line for "did the criteria give the right answer, fast enough?", and the answer feeds back into the card. A card that has not changed in a year is either perfect or unread. It is the second one.

One last habit makes the card work: write the four answers in the first note of the incident ticket. The written answers are what you will show the manager who asks "why did we declare?" and, more often, the one who asks "why didn't we?". The card is the answer to both.

A Short War Story: The Slow Tuesday at Tollgate Foods

Tollgate Foods, a regional food distributor with a two-person desk, had its order and routing system slow to a crawl at 09:15 on a Tuesday. The technician on duty, Marek, spent the morning working it as a normal ticket because nothing was actually down. The server was up, and the database answered. His manager had once told him that "the business does not want to hear the word outage over a slow screen". By 11:30 the warehouse had picked from memory and printed lists for two hours. The drivers had left with half-loaded vans rather than miss their windows. Forty-two orders for the day's chilled run missed the 11:00 cut-off and went out a day late. That cost Tollgate a delivery credit on each and one customer who moved their account. The cause turned out to be a database job that had started early and was holding a lock. It took eleven minutes to stop once someone was looking for it rather than at it. The review found that Marek had done every technical thing right and one organisational thing wrong. He had tested the server, which was fine, instead of the process, which had stopped at 09:20. Tollgate's criteria card now has "picking has stopped or slowed to the point of stopping" as the first line. The words "whether or not anything is down" follow it. A process that has stopped is major whatever the ping says.

The Major-Incident Criteria Card

The card below is the one page that should exist before the first incident. Fill in the never-pause processes with the business, write the declaration rule in one line, pin a copy at the desk, and put the same text at the top of the playbook. Run the four questions out loud, write the answers into the first note of the incident ticket, and let the verdict follow from the answers rather than from how the morning feels.

MAJOR-INCIDENT CRITERIA CARD — ONE PAGE
Desk: __________________   Last reviewed: ____________   Owner: ____________

WHAT MAJOR MEANS HERE
  A break that we stop working as ordinary tickets and run as one
  coordinated response: one incident ticket, one lead, one fixer,
  updates on a fixed interval, other work paused.

THE THREE CRITERIA
  1. People affected   A group cannot work: a team, a site, a shift,
                       everyone who uses one system. One person, however
                       senior, is a priority ticket, not a declaration.
  2. Process stopped   A named business activity has halted or slowed to
                       the point of halting. Name the activity, not the
                       system. Slowness counts.
  3. No workaround     The affected people cannot do the work another
                       way, or the other way will not hold for an hour.
  Verdict: two of three = major. One of three = major only if the process
  is on the never-pause list below.

NEVER-PAUSE PROCESSES (agreed with the business)
  [ ] __________________________  owner: __________  hours: __________
  [ ] __________________________  owner: __________  hours: __________
  [ ] __________________________  owner: __________  hours: __________
  [ ] __________________________  owner: __________  hours: __________

NOT MAJOR ON ITS OWN
  [ ] One important person's device          -> top-priority ticket
  [ ] Many tickets, one small cause, workaround exists -> one reply to all
  [ ] A planned outage, however badly announced
  [ ] A security event (run the security playbook; may also be major)

WHO MAY DECLARE
  Anyone on the desk may propose. Declares: ______________________
  (role, not a name). On a two-person desk: either person.
  The manager is told within 15 minutes and may stand down, not hold.

THE DOUBT RULE
  If after ____ minutes you cannot call it a ticket, call it major.
  A short incident costs one message. An undeclared one costs the hour.

THE FOUR QUESTIONS (say them out loud; write answers in the first note)
  1. Who cannot work right now, and roughly how many? __________________
  2. Which process, in plain words, has stopped? ______________________
  3. Is there a workaround, and will it hold an hour? _________________
  4. Is this a never-pause process? ___________________________________
  Verdict: [ ] major, declared at ____:____   [ ] ticket, priority ____

The card changes a little with the desk. A clinic puts its never-pause list first and the doubt rule at two minutes. A distributor writes the cut-off times next to the processes, because the same break is a ticket at 15:00 and major at 09:00. A solo administrator replaces "declares" with their own role and adds the name of the one person they tell. What does not change is the shape: three questions about the organisation, a list the business wrote, and a one-line rule about who says the word.

Back at Meridian Parts, the order system was a full database disk, found at 11:05 and cleared by 11:20. The pick team had the 14:00 courier loaded with ten minutes to spare. The incident was thirty-seven minutes long and produced four messages. Tomas's first note in the incident ticket has the four answers in it, in his own words. The dispatch supervisor has stopped writing "down" in capitals, because the desk now has a word for the thing he meant.

Frequently Asked Questions