Declaring an Incident and the First Fifteen Minutes

08:20 on a Monday at Harbourview Clinic. The patient records system has stopped answering. Reception has thirty-one appointments before noon and a waiting room that is already filling. And the two-person desk, Nadia and Owen, are both typing. Owen is restarting the application service. Nadia is on the phone to the practice manager, who wants to know whether to send patients home. Meanwhile, Nadia is trying to read the database log with her other hand. Reception has raised four tickets. A nurse has walked to the desk. Nobody has said the word yet, because saying it feels like admitting something. Both of them are busy enough to feel that they are already dealing with it. They are dealing with it twice, which is the problem.

A declaration is the moment the word "major incident" is said out loud, written down, and acted on. One ticket is opened, two or three roles are named, and a first message goes out. And the desk stops working as a queue and starts working as a response. The first fifteen minutes are a fixed sequence of small steps, done in order. They get the desk from "both typing" to "one fixing, one talking, everyone else told". This article is part of our Major Incident Management for Small Teams series, and it is about those fifteen minutes.

It covers what the declaration message says and where it is said. Next come the three roles, lead, communicator and fixer, and how two people hold them. We cover the incident ticket and what goes in it, then linking the related tickets so the flood stops. We move on to telling the manager and clearing the desk, then the five things that go wrong in the first quarter of an hour. Next come a minute-by-minute table by role and a short war story. We finish with the first-fifteen-minutes checklist to pin by the desk, in that order.

The Declaration Is a Sentence, Not a Feeling

The declaration is one written sentence with six parts, and it is the same sentence every time. It includes the words "major incident declared", the time, and what is broken in plain words. It says who cannot work, whether there is a workaround, and who is lead and who is fixer. "Major incident declared 08:22: patient records system unavailable, all clinical staff affected, workaround is paper forms, lead Nadia, fixer Owen, next update 08:40." That is the whole thing. It goes in the team chat, or whatever the desk uses to talk to itself. And it goes as the first note of the incident ticket, word for word.

It is written rather than said because a spoken declaration evaporates. Twenty minutes later, nobody can agree whether it was 08:20 or 08:25. The manager who joined at 08:40 has no idea what was decided. The review on Thursday is reconstructed from memory by two people who were not listening to each other at the time. The written sentence is the first line of the timeline, and the timeline is what the review runs on. Whether a thing qualifies at all is the previous article's job, What Makes an Incident Major. The four answers from its test belong in the same first note.

Say it to the desk first and to the building second. The declaration is for the people who will run the response. The first notice, which goes to everyone affected, is a different message with a different shape and is sent a few minutes later by the communicator. Desks that send one message to both audiences end up with a nurse reading "fixer Owen" and a technician reading "we apologise for the inconvenience". Neither of those sentences helps the person reading it.

Three Roles, Two People

A major incident needs three jobs done at the same time, and the jobs are roles rather than people. The lead decides whether it is major and what the fixer tries next. The lead decides when to escalate to a supplier, when to tell the manager, and when to send the all-clear. The lead keeps the timeline and owns the incident ticket. The communicator talks to everyone who is not fixing. They send the fixed-interval updates, answer the phone, and reply to the tickets that keep arriving. They say "I will pass that on" rather than "let me just check". The fixer has hands on the system and speaks to exactly one person, the lead. The fixer speaks only when there is something to say or a decision to ask for.

With two people, the lead is also the communicator and the other person is the fixer. That split is the whole secret of running an incident on a small desk, and it is the one most desks get backwards. The instinct is for the senior person to fix and the junior person to "handle the phones". That produces a fixer who is being asked questions by the one person who could have answered them. The senior person is usually the better fixer. And it is still often right for them to lead, because the lead's job is judgement and the fixer's job is hands. Decide it in the playbook, not at 08:22, and let it depend on what is broken. The person who knows the records system fixes the records system.

With one person, all three roles live in one head, and the only way that works is a timer. The solo administrator fixes, and every fifteen minutes the timer goes off. They stop fixing for two minutes, write one line in the log, send one update, and go back. It is slower than fixing straight through, and it is faster than fixing straight through while answering the phone at random intervals, which is the alternative. With three or more people, the communicator role is the first one to split off, because it is the one that most interrupts the lead. The third person who walks in takes the phones, the updates and the tickets, and the lead goes back to deciding.

The picture below shows the three roles on one timeline for a two-person incident that lasts about seventy-five minutes. Dana holds the lead role from the declaration to the all-clear. Dana holds the communicator role as well until a third person arrives at about minute thirty-five and takes it over. Priya is the fixer throughout, uninterrupted, and applies the fix at minute sixty. The lower line is the messages: declared at zero, first notice at five. There is an update every fifteen minutes whether or not there is news, and the all-clear at seventy-two.

The fixer does not communicate, and this rule needs saying three times because it is broken three times in every incident that has no roles. Every question asked of the fixer costs the answer plus the five minutes it takes to get back to where they were. The communicator's whole purpose is to be the person questions bounce off. "Owen is on it, I will have an update at 08:40, is there anything you need in the meantime?" is a complete answer to every question in the first hour, including the practice manager's. The fixer, meanwhile, is allowed to ignore the chat window. That is what it is for.

Minute Zero to Five: Say It and Open the Ticket

The first five minutes are the declaration and the incident ticket, in that order, by the lead. The incident ticket is one ordinary ticket that stands for the whole incident. It has the declaration sentence as its first note, the four test answers under it, the top priority, and the lead as its owner. Its subject starts with a fixed prefix such as "MAJOR:" so that it can be found by anyone searching. The requester on it is the desk itself, or the lead, not the first person who happened to report the problem. The thirty people who reported it have their own tickets, which are about to be linked.

Some tools have an incident type, a "major incident" flag, or a parent-and-child relationship between tickets. Many small-team tools have none of these, and the prefix convention works in all of them. Check yours for three things. Can a ticket be marked as related to another? Is a merge reversible (in many tools it is not)? Can a saved search or view be made for the prefix? If the answer to the first is no, the link is a line in the notes ("see MAJOR ticket 5120") on both tickets. That is less elegant and entirely adequate. The incident ticket uses the same fields as any other ticket, with one extra rule, which is that its history is the timeline.

Open the ticket before the fix, not after. The temptation at minute two is to "do the ticket in a minute", and the minute arrives at the all-clear. By then everything that happened is in the chat scroll-back, three heads, and nowhere else. A ticket opened at minute three with one note takes ninety seconds. A ticket reconstructed at minute ninety takes an afternoon and is wrong. The fixer may already be fixing during these five minutes; the declaration does not need their attention, only their name.

Minute Five to Ten: Link the Tickets and Send the First Notice

The next five minutes stop the flood. Every ticket that is about the incident gets linked to the incident ticket, by whatever mechanism the tool has. Each gets one reply: "This is part of a wider problem we are working on as a major incident; updates will come every twenty minutes; you do not need to do anything." Then those tickets are left alone until the all-clear. The communicator does this, which on a two-person desk means the lead does it, between the declaration and the first notice. Four tickets takes two minutes. Thirty tickets takes ten, and is worth every one of them, because thirty people who have been told are thirty people who will not phone.

Resist merging. Merging combines tickets into one, and in most tools the result is a single ticket with one requester. That means twenty-nine people stop receiving replies and one person receives twenty-nine people's history. Link, reply, and leave each ticket open with its own requester, so that the all-clear reaches every one of them in their own thread. If your tool can send one reply to many tickets at once, use it; if it cannot, a saved reply pasted thirty times is still ten minutes. The desk will want to stop new duplicates arriving too. A banner on the portal, a line in the automatic acknowledgement, or a notice on the phone greeting does that where the tool allows. Where it does not, the first notice does the same work by reaching people before they report.

The first notice goes out at about minute five to everyone affected. It says what is broken, who is affected, the workaround if there is one, and when the next update will come. It is the communicator's message, and its exact shape, along with the update and the all-clear, is in Communicating During the Incident. What matters in the first fifteen minutes is that it goes out before anyone has a cause. The people in the waiting room do not need the cause. They need to know that paper forms are fine and that someone will tell them more at 08:40.

Minute Ten to Fifteen: Tell the Manager, Clear the Desk, Start the Log

The manager gets one message from the lead by minute fifteen. It is the declaration sentence plus one line: "I will update you at the same interval as everyone else; if you need a decision from me before then, reply here." That line is doing a lot of work. It tells the manager that they are on the update list and do not need to come to the desk. It tells them how to reach the lead if they must. And it sets the expectation that they will be hearing from the communicator rather than the fixer. A manager who is told early and told how they will be told rarely appears behind the fixer's chair. One who is not told will appear at minute twenty with a question. And the question will be "what's happening?", which is the one the update was going to answer.

Clear the desk by telling the queue what is happening to it. Everything that is not the incident waits, and the people whose tickets are waiting should know why. Put a one-line note in the queue's shared view, or a line in the auto-acknowledgement saying new tickets will be looked at after the incident. On a two-person desk nothing else is going to get done anyway. The point of saying so is that nobody spends the incident feeling guilty about ticket 5098. Nobody outside the desk thinks it was forgotten, either. Pausing is a decision. Make it once and write it down.

Start the log at minute fifteen if it has not started already, and from here on it is the lead's main artefact. The timeline log is a list of timed one-line entries: what was seen, what was tried, what was decided, who was told. It is kept in the incident ticket's notes or in a document whose link is in the ticket. Its format, and the discipline of keeping it while also talking to people, is the subject of Coordinating a Major Incident With Two People. By minute fifteen it has about five lines, and that is the right number. The log is the only part of the incident that will still exist on Thursday.

Set the next update time before minute fifteen ends, and set it on a clock rather than a condition. "Next update 08:40" can be kept whether or not anything has changed. "Next update when we know more" is a promise that the people in the waiting room cannot plan around and that the desk will forget to keep. The interval itself is a playbook decision. Fifteen to thirty minutes is the usual range, shorter when people are standing up and longer when the workaround is comfortable.

What Goes Wrong in the First Fifteen Minutes

Five things go wrong, and all five come from skipping the declaration. The first is both people fixing, as at Harbourview at 08:20. That means two sets of hands on one system with no agreement about who is doing what. The war story below is what that costs. The second is nobody opening the ticket, so the history lives in a chat window that scrolls and in heads that forget. The third is the fixer answering the phone, because nobody told the phone to ring somewhere else. The fourth is the manager arriving at the desk, because nobody told them they were on the list. The fifth is the first notice going out at minute forty, with a cause in it, after thirty people have reported the same thing and twenty have walked over.

There is a sixth, quieter one: the fixer making changes that nobody records. A restart, a config edit, a failover, a password reset on a service account, each done in a hurry and each a change to a live system. During an incident they are emergency changes, changes made without the usual review because waiting would cost more. The desk still has to know afterwards what was changed. The rule that makes this survivable is that the fixer tells the lead before each change in one line. The lead writes it in the log with the time. The fuller treatment of what to do about those changes once the incident is over is in Emergency Changes. For now the line in the log is enough.

The table below is the fifteen minutes laid out by role, for a two-person desk where the lead is also the communicator. Read down your own column. If you are the fixer, your column is short, and that is deliberate. Everything not in it is someone else's job, including the thing the practice manager just asked you.

A desk of three moves the first-notice row and the link-tickets row to the third person. And the lead's column becomes mostly decisions and the log. A desk of one does the lead's column in the gaps between the fixer's column, with the timer, and leaves the link-tickets row until the first update. The order inside the lead's column does not change with the size of the desk.

Handing Over Mid-Incident

Sometimes the roles change hands before the incident is over, and the handover is itself a line in the log. A third person arrives and takes the communicator role. The lead writes "08:51 Sam takes comms; next update still 09:00". The lead tells Sam the interval, the workaround, and where the list of linked tickets is. The fixer hits the limit of what they know and the lead swaps them with someone who knows the system better. The log records: "09:10 Priya takes fixer from Owen; Owen briefs her for three minutes; nothing changed on the system during the brief." The brief is spoken, the fact of it is written, and the incoming person reads the log before touching anything.

The lead role changes hands last and least, because the lead is the one person with the whole picture. The picture is expensive to transfer. If the lead must leave, the log is the handover. In that case, the outgoing lead's final entry says who is lead now and what the next decision point is. The patterns for handing work between people without dropping it are the subject of The Shift Handover. And an incident handover is the same discipline with the stakes turned up.

A Short War Story: Two Pairs of Hands at Redbrook Engineering

Redbrook Engineering, a design consultancy with a three-person desk, lost its shared drawing store at 14:05 on the day before a tender deadline. Two of the technicians, Lukas and Amira, started fixing it at the same time from different desks without either of them saying the word incident. Lukas restored the previous night's configuration of the storage service. Meanwhile Amira, unaware, restarted the same service twice to clear what she thought was a hung process. That rolled Lukas's restore back halfway through and left the service in a state that neither of them recognised. The third technician spent the same hour on the phone telling the design team that it would be "a few minutes". The store came back at 16:20, two hours and fifteen minutes after it went down. The review later estimated that ninety minutes of that were spent undoing the effect of two people's work on each other. The tender went in at 23:40 with two drawings missing, and the firm's managing partner asked, reasonably, who had been in charge. The answer was nobody. Redbrook's playbook now begins with a single line that must be written in the chat before anyone touches anything. It names who is lead, who is fixer, and the time.

The First-Fifteen-Minutes Checklist

The checklist below is the whole article on one page, in the order the steps happen, with a box for each. It is written for a two-person desk where the lead is also the communicator. A solo desk works it top to bottom with a timer, and a larger desk moves the communicator lines to a third person. Pin it where the desk sits, keep a copy at the top of the playbook, and tick it with a pen during the real thing. The ticks are themselves the first page of the review.

FIRST FIFTEEN MINUTES — MAJOR INCIDENT CHECKLIST
Declared at: ____:____   Lead: ____________   Fixer: ____________
Communicator (if a third person): ____________

MINUTE 0 TO 5: DECLARE AND OPEN
  [ ] Four-question test run; answers noted (who, process, workaround, never-pause)
  [ ] Declaration sentence written in the team chat:
      "Major incident declared __:__ : ______________ unavailable,
       ______________ affected, workaround ______________,
       lead ________, fixer ________, next update __:__"
  [ ] Incident ticket opened; subject prefix "MAJOR:"; top priority
  [ ] Declaration sentence and test answers in the first note
  [ ] Lead set as owner; requester is the desk, not the first reporter

MINUTE 5 TO 10: NOTICE AND LINKS
  [ ] First notice sent to everyone affected (what, who, workaround, next update time)
  [ ] Every related ticket linked to the incident ticket (or ticket number noted on both)
  [ ] One reply sent to each related ticket; tickets left open, not merged
  [ ] Duplicate flow slowed: portal banner / auto-reply line / phone greeting, if available

MINUTE 10 TO 15: MANAGER, QUEUE, LOG
  [ ] Manager messaged: declaration sentence + "updates at the same interval; reply here for a decision"
  [ ] Queue paused with a one-line note where the desk and requesters can see it
  [ ] Timeline log started: declaration, first symptom, first check, first notice, manager told
  [ ] Next update time set on the clock, not on a condition: __:__

STANDING RULES FOR THE WHOLE INCIDENT
  [ ] Fixer speaks only to the lead; all questions go to the communicator
  [ ] Fixer tells the lead before every change to a live system; lead logs it with the time
  [ ] Updates go out at the interval whether or not there is news
  [ ] Any change of role is a line in the log with the time

Back at Harbourview, Nadia said the sentence at 08:24, four minutes later than she would have liked. That was about forty minutes earlier than the desk would have managed without a checklist. Owen stopped restarting things and found a full transaction log at 08:41. The first notice went out at 08:29 with "paper forms are fine, next update 08:45" in it. Reception, who had been raising tickets every six minutes, raised none after that. The practice manager got one message, replied "noted", and did not come to the desk. The system was back at 09:02, and the log had fourteen lines in it, the first of which had the time on it.

Frequently Asked Questions