The First Notice: Say Something in Five Minutes

Tuesday, 08:52, at Meridian Parts. The order system, the screen the sales desk takes orders on and the warehouse picks from, has stopped responding. Dana on the help desk takes three calls in the first minute, each one beginning "is it just me?" She does not know what is wrong. Her instinct, which is a good instinct in almost every other situation, is to find out before she says anything. By 09:05 she has taken fourteen calls. The sales manager is standing at her desk. Someone in the warehouse has told the drivers it will be "down all morning". Nobody said that, and it is now the official version. Dana still does not know what is wrong. She also has not told anyone anything, and the second fact is costing more than the first.

A first notice is the first message the desk sends to the people affected by an outage. It goes out within about five minutes of knowing the outage is real, and before anyone knows the cause. An outage, for this series, is any service that more than one person relies on not working, or not working properly. The first notice has three lines: what is affected, that you know and are working on it, and when the next update comes. It contains almost nothing, and that is the design. This article is part of our Outage Communication series. It is about the messages an outage needs, who they go to, and when. The incident itself and the roles behind it have a series of their own.

It starts with why the notice goes out at five minutes and not when you understand the problem. Next come the three lines and the words to use in each, then what the first notice must leave out. After that: who sends it and from where, and deciding whether a problem deserves a notice at all. Then comes the same notice shaped for each audience, and writing it in advance so it takes two minutes on the day. It ends with a short war story and the first-notice template to copy.

Why Five Minutes, Not When You Understand It

The notice goes out early because people are already finding out the hard way. In the minutes after a service stops, every person who relies on it runs the same private checks. They restart the program, restart the computer, ask the person at the next desk, and phone the help desk. Each check takes a minute or two and produces a rumour. By minute ten there are forty people doing this. The desk's phone has become the status channel, delivering one fact to one person at a time. The person who could fix the problem is answering it. Five minutes is roughly how long you have before the calls arrive faster than one person can pick them up.

The notice does not wait for the cause, because at minute five there is no cause, and the people affected do not need one. They need three things: confirmation that it is not just them, confirmation that somebody knows, and a time at which they will hear more. That is the entire content of the first notice, and all three are known at minute five. The cause, the fix and the explanation belong to later messages. Waiting for them is the most common mistake in outage communication and it feels like the responsible choice while you are making it. "I didn't want to say anything until I knew what was going on" is the sentence that precedes every late notice I have ever been asked to review.

What the notice buys is quiet. Every person who reads it stops restarting, stops phoning and stops telling their colleagues a version of their own. Forty private investigations collapse into one shared fact. The desk gets twenty uninterrupted minutes to work on the problem. That is the thing the people affected want most. They will never get it while the desk is on the phone to them one at a time. The notice is ninety seconds of typing. It is the cheapest ninety seconds of the whole outage.

Line One: What Is Affected, in Their Words

Line one names the thing that is not working, using the name the people affected use for it. At Meridian the sales desk says "the order system". The desk's documentation says "the ERP application server". Only one of those phrases means anything to a person holding a phone with a customer on it. If several things are affected, list the ones people would notice, not the components behind them. "The order system and the stock screen" is a line one. "The database cluster" is a line one that will be read as "something technical is broken" and then ignored. Where a thing has several names, use the one on the icon people click.

Add a time and a scope. "Since about 08:50" tells the reader their own experience matches. That is the reassurance they were phoning for. It also gives everyone one agreed start time for later. Scope is who is affected: "everyone", "the sales office and the warehouse", "anyone working from home". If you do not know the scope yet, say what you do know: "at least the sales office; please tell us if you are affected elsewhere." That sentence turns the next ten phone calls into useful information instead of repetition.

Say what the reader will see, if you can, in one phrase. "The screen shows 'cannot connect'" or "orders save but do not print" lets each person confirm they have the same problem rather than a different one. It stops the desk receiving a second outage's worth of unrelated tickets under the first outage's name. Describing the symptom is not describing the cause. The symptom is what they are looking at. The cause is what you are looking for.

Line Two: That You Know, and Are On It

Line two says the desk knows and is working on it, and it says so in those words. "We know about this and we are working on it now" is plain, true, and complete. It does not need "we are working hard", because nobody imagines the desk is working gently. It does not need "we take this very seriously". The sentence that most reliably signals that nobody is taking something seriously is the one that says so. Twelve words of reassurance contain no information, and everyone who reads them knows it.

If there is a workaround at minute five, line two carries it. A workaround is a way for people to keep working while the real thing is broken. For example: take orders on the paper pad, use the phone instead of the chat tool, save files locally and copy them later. Often at minute five there is none. In that case the useful content of line two is what not to do: "Restarting your computer will not help; please do not reinstall anything." That line sounds trivial and saves hours. The restart is a ritual. Every ritual takes four minutes, and forty people will perform it in parallel while they wait for you.

Do not promise a fix in line two, even softly. "We expect this to be resolved shortly" has two problems. "Shortly" means a different thing to every reader. When it turns out to mean two hours the desk has broken a promise it never meant to make. The rules about what a desk may promise and what it must never promise are in What to Promise and What Never to Promise. The first notice is the moment those rules are easiest to break, because the reader wants an estimate and the writer wants to be kind. Be kind with line three instead.

Line Three: When the Next Update Comes

Line three gives a clock time at which the next message will arrive, whether or not anything has changed. "Next update by 09:20, even if there is no news" is the most important sentence in the notice and the one most often left out. It is what makes the notice believable, because it is a promise the desk can keep with no information at all. It is also what stops the phone, because a person who knows when they will hear next does not need to ask. "We will update you as soon as we know more" is not a line three. It is a line three with the time removed, and the time was the point.

Pick the time from a default, not from the situation. Decide now, while nothing is broken, that the first update after a notice comes twenty minutes later, or fifteen, or thirty. Write that into the template so that line three is arithmetic rather than a judgement made under pressure. The interval can change later. How it changes with the severity of the outage is the subject of Update Cadence During an Incident. At minute five the only wrong answer is "soon".

Put the time in the subject line as well, because most people read the subject and nothing else. "Order system not working since 08:50; next update 09:20" is a complete first notice in one line. A person who sees it in a notification on their phone has everything they need without opening it. The body repeats it with the detail. If your organisation announces in a chat channel rather than by e-mail, the first line of the message is the subject line, and the same rule applies.

What the First Notice Leaves Out

The first notice leaves out the cause, including the probable one. At minute five a cause is a hunch, and a hunch in writing becomes a fact the moment it is forwarded. "It looks like a network issue" will be repeated at the warehouse and quoted by the sales manager. When the cause turns out to be an expired certificate, it will be remembered as the time the desk got it wrong. The reader does not need the cause to act. The desk does not need to have said it. Nothing is lost by leaving it until the all-clear, when it will be true.

It leaves out the fix time, the long apology, and anyone's name as the reason. A fix time at minute five is a guess with a deadline attached. An apology longer than one clause reads as a message with no content. The real apology is the workaround and the next update arriving on time. A name, whether a supplier, a colleague or "the people who did the change last night", will be read by the person named. Every outage message is forwarded further than its author expects. "Sorry for the disruption" is the whole apology. The rest is for the after-note.

It also leaves out the technical detail that the writer finds interesting. That is a harder habit to break because the detail is true and the writer has just discovered it. The test for every sentence is whether a person who has never seen the desk could act on it in the next minute. "Please take orders on the paper pad and we will key them in afterwards" passes. "The application pool has stopped responding to health checks" fails, and takes a line of the reader's attention with it. Write to the person at the counter. The person at the counter is not reading for background.

Who Sends It, and From Where

One named role sends the first notice, and the role is decided before the day. On a desk of two or three, it is whoever picked up the outage first, and the message says so: "Dana, help desk". On a desk that runs incidents with a lead, it is the lead, from the moment of declaring, as described in Declaring and the First Fifteen Minutes. What matters is that the people affected see one name on every message of the outage. That name must belong to someone who is not also holding the screwdriver. The person fixing the problem does not write the notices. A fixer who stops to write a notice has stopped fixing, and a fixer who does not stop has left the notice to nobody.

The notice goes out from the desk's shared address, not from anyone's personal one. The reason is what happens next: forty people reply. Some say "me too", some say "I am not affected", some ask a question, and a few supply the one detail that identifies the cause. From a personal mailbox those replies are forty unread messages competing with everything else. From the desk's address they land in the queue as tickets, where they can be counted, linked to the outage and answered together. If you run QuerySolv, a reply to a notice sent from the desk's mailbox arrives as an ordinary ticket. It joins the same queue as the web-form and chat reports of the same outage. So the "me too" replies become the count of who is affected rather than a pile in someone's inbox.

On a one-person desk, the notice still goes out before the fixing starts, and it goes out first because of what it buys. Two minutes of writing earns twenty minutes without the phone, and a solo administrator with twenty quiet minutes fixes most things. A solo administrator who starts fixing first spends the twenty minutes explaining to callers, one at a time, that they are trying to fix it. The arithmetic is not close. Write the notice, then pick up the screwdriver.

Is This a Notice at All?

Send a notice when three conditions hold. More than one person is affected. The service is one that others rely on. And you cannot fix the problem in the time it would take to write the message. Three reports of the same thing inside ten minutes is a reliable signal. So is one report from a person whose job is to notice that others are affected, such as a receptionist or a shift supervisor. One person's printer is a ticket. The printer that the whole dispatch office uses is a notice, even though the fix may be identical. The people around it are about to start asking each other whether it is just them.

The cost of each mistake is different, and that decides which way to lean. A notice about something that affected only one person teaches the organisation that notices are noise, and the next notice gets filed unread. A missing notice about something that affected a department teaches the organisation that the desk does not say anything. The next outage is reported by phone forty times. Both costs are real, but the second compounds, because every rumour it creates has to be corrected later. When the affected group is a team or more, send it.

The threshold for a notice is lower than the threshold for declaring a major incident, and the two should not be confused. What Makes an Incident Major describes the conditions that justify a lead, a bridge call and a timeline. Most outages that deserve a first notice never reach that bar. They affect one office for forty minutes and are fixed by a restart. They still get a notice. The notice is not a declaration of anything except that the desk knows. The question that decides it is whether you would otherwise get the call that begins "is it just me?" If you would, send it.

The Same Facts for Every Audience

An outage has more audiences than the people whose screens went blank. The first notice reaches all of them with the same facts and a different first line. The people affected need what to do. Their managers need the same message plus one line about what the desk needs from them. Usually that is "please tell your team" or "no decision needed yet". Senior management needs one sentence about the business effect, written in the business's words: "orders cannot be taken by phone; the web shop is unaffected". People outside the organisation, when the outage reaches them, need fewer words still, no internal system names, and one place to look for updates. Whoever answers the main phone needs a single sentence they can say aloud.

Never send different facts to different audiences, because the versions will meet. The store manager will forward the user notice to the regional manager, who has the management version. Any difference between them is a question the desk now has to answer during the outage. Write one set of facts once, then change only the first line and the length for each audience. The three lines stay the three lines. The manager's version has a fourth. The receptionist's version is the subject line, said aloud. The table below puts the versions side by side.

Choosing the Channels for Outage Messages explains where each route works and what to do when the route itself is broken. That includes the familiar problem of announcing an e-mail outage by e-mail. For the first notice the rule is short: use the two routes that reach the most affected people fastest. Use the same two for every message of the outage, so that nobody has to guess where to look.

Writing It in Advance

The first notice is written before the day, with blanks for the five things that change: the service, the time, the scope, the workaround, and the next update time. Everything else is fixed text, agreed once, and not reconsidered at 08:57 with the sales manager standing at the desk. Keep it in the incident playbook and as a saved reply in the ticketing tool if the tool has them. Also keep a plain text file in a place that will still be reachable when the server is not. I kept mine on the file server for two years. You can guess which outage taught me where to keep it instead.

Prepare the names in advance as well. Make a short list of the services the desk supports. Give the name the desk uses, the name the users use, and who relies on each. Then line one is a lookup rather than a translation. "ERP-APP-01: the order system: sales office, warehouse, three drivers" is the entire entry. The list also answers the scope question before anyone phones, because the people who rely on a service are written next to it. Most desks have this list somewhere already, under a different heading, in the service catalogue or the monitoring configuration. Copy it onto one page.

Rehearse once, with a clock. Hand the template to the newest person on the desk, name a service, and time how long it takes them to produce a sendable notice. Under two minutes is the target and most people reach it on the second try. The first try usually reveals a blank nobody can fill, which is exactly what the rehearsal is for. A notice that takes eight minutes to write on a quiet Thursday will take twenty on the day, and the day is the only time it is needed. The wider library of saved replies, and how to keep it alive, belongs to the templates series in this library. The first notice is the one template every desk should own before it owns any other.

A Short War Story: The Notice That Waited at Tollgate Foods

Tollgate Foods ran a two-person desk. At 06:30 on a Thursday the label printing in the dispatch warehouse stopped, forty minutes before the morning vans were due to leave. Marcus, who was on early, decided to find the cause before he worried anyone. He found it at 07:10: a certificate on the print server had expired overnight. Renewing it took four minutes. In the forty minutes he spent looking, a driver asked the warehouse supervisor what was happening. The driver was told "IT said it would be a while", which nobody in IT had said. The supervisor, believing it, sent eleven vans out with handwritten labels. Two went to the wrong depots, and all had to be rescanned on return. The review put the cost at a morning of redelivery, roughly sixty late orders and one customer who moved a contract to review. A notice at 06:35 could have said "label printing is down since 06:30, we are on it, hold the vans, next update at 06:55". It would have held the vans for twenty-five minutes and cost nothing. Marcus now sends the notice before he opens the server console, and says so in it.

The First Notice

The template below is the three-line notice with its subject line, the one-line versions for the other audiences, and a thirty-second check to run before sending. Fill the blanks, delete nothing else, and send. The words outside the blanks have been chosen to be read by someone standing at a counter with a customer waiting. That is the reader every outage message should be written for.

THE FIRST NOTICE — THREE LINES
Send within five minutes of knowing the outage is real. The cause is not needed.

Subject: ____________________ not working since about __:__ ; next update __:__

1. WHAT    ____________________ (the service, in the users' words) is not working
           since about __:__. Affected: ____________________ (who, or "everyone").
           What you will see: ____________________ (the symptom, one phrase).

2. ON IT   We know about this and we are working on it now.
           Meanwhile: ____________________ (the workaround, or "please wait;
           restarting your computer will not help").

3. NEXT    Next update by __:__, whether or not anything has changed.

Sorry for the disruption.
-- ____________ (name and role), help desk, from ____________ (the desk address)

ONE-LINE VERSIONS OF THE SAME FACTS
  Managers (add as a fourth line to the notice above):
    "From you: please tell your team. No decision is needed yet."
  Senior management (one sentence, same channel they normally use):
    "Business effect: ____________________. Next update __:__."
  People outside the organisation (no system names, no cause):
    "____________________ is currently unavailable. The team is working on it.
     Next update at __:__ at ____________________ (where to look)."
  Whoever answers the main phone (to say aloud):
    "____________________ is down since __:__. IT knows. Update at __:__."

THIRTY-SECOND CHECK BEFORE SENDING
  [ ] The service is named the way its users name it
  [ ] A start time in line one and a clock time in line three
  [ ] No cause, no fix estimate, no name as the reason
  [ ] Sent from the desk address, not a personal one
  [ ] The same facts going to every audience
  [ ] The next update time is written in the timeline log

Dana sent her first notice at Meridian the following month, at 10:14, four minutes after the second "is it just me?" call. It was about a stock screen that had stopped loading. The notice said the stock screen was down since about 10:10 and that the desk knew. The order screen still worked, and stock could be checked by phone with the warehouse. The next update would come at 10:35. The desk took two calls in the next twenty minutes, both from people who had not seen the notice yet. The stock screen was back at 10:31. The notice took her ninety seconds to write, and she has not found a faster way to make a phone stop ringing.

Frequently Asked Questions