Planned-Maintenance Notices People Actually Read

Monday, 08:05, at Ashgrove Housing. The five neighbourhood offices have opened and the tenancy system is not there. Every housing officer uses it to look up a tenant before saying anything to them. Owen on the desk knows exactly why: the Saturday upgrade overran and the supplier is still finishing it. He sent a notice about the whole thing the previous Tuesday. He pulls it up to prove it. Subject line: "Scheduled Maintenance Notification". Eleven lines, two about the version being installed, one about the window, none about Monday morning. The first housing officer to phone says "nobody told us". Owen opens his mouth to say that they were told, and closes it again. He has just reread the notice and he would not have read it either.

A planned-maintenance notice tells people, in advance, that a service will be unavailable or will change at a chosen time. It says what they will see, what to do before and after, and when it will be back. It comes in two parts, an advance notice and a reminder. It has a third part that most desks never write: the message for when the work runs late. This article is part of our Outage Communication series. It is about the notices. The decision about whether the work needs review, and the record that describes it, belong to change management. This article picks up once the work is approved and somebody has to tell the people it will affect.

It covers why maintenance notices go unread, then the two messages and when each is sent, with a table of lead times. Next come choosing the window with the people affected, what to expect in plain words, and the subject line. Then come where the notice goes and how long it stays, the maintenance that overruns, and the done message afterwards. Postponing and cancelling, a short war story, and the maintenance notice to copy follow, in that order.

Why Maintenance Notices Go Unread

Maintenance notices go unread for four reasons, and none of them is that people do not care about downtime. The first is that the notice is sent once, a week early, and nothing arrives nearer the time. A message read on Tuesday about Saturday is forgotten by Thursday. The second is that it is written in the desk's words, about the desk's work: the system's internal name, the version, the component, the reason. None of that tells a housing officer what Monday looks like. The third is that every notice has the same subject line. So the one about the system they use looks exactly like the six about systems they do not. The fourth is volume: a desk that sends a notice for every trivial restart has trained the organisation to file them unread. And the notice about the big one goes into the same folder.

Underneath all four is a notice that does not tell the reader what to do. People read messages that ask something of them and skim messages that inform them. "The system will be unavailable" without "so save your work and log off by 16:45" is information with no handle. The question a reader brings to any notice is "what does this mean for me on the day?" And a notice that answers it in the first two lines gets read to the end. One that answers it in line nine, after the version number, does not get to line nine.

The eleven-line notice with the version number in it was written for the wrong reader. It was for the desk's own record, or for the manager who approved the change. It was then sent to all staff because that was the list to hand. The record of the work, with its risk, rollback and test, is described in The One-Page Change Record. The notice is a different document for a different reader, and it is shorter.

Two Messages, Not One

Every planned maintenance that affects people gets an advance notice and a reminder, and the reminder is the one that gets read. The advance notice goes early enough for people to plan around the window. They can move a deadline, finish a report, warn a customer, or avoid scheduling the staff meeting in the system that will be down. The reminder goes the working day before, or the morning of an evening window. At that point, the reader can still do the one thing the notice asks. The reminder says the same facts again with the time nearer. For anything in working hours, a third line goes out at the moment the work starts. By then the reminder is yesterday's e-mail and the reader has a screen that has just stopped.

Lead time scales with how many people are affected and how much they have to prepare. A change that touches the whole organisation, or that people need to prepare for, gets five to ten working days of notice. It also gets a reminder the day before. A change to one team's system gets two or three working days and a reminder the morning of. A restart that costs five minutes out of hours gets the reminder only, if anything. Decide the bands once and write them down next to the change kinds the desk already uses. That way, a technician planning work knows on Tuesday when the notice has to go. They do not discover on Friday that it should have gone on Monday.

The table below is a starting set of lead times by the scale of the work. The right-hand column, who is told, is the one most often got wrong, because the easy answer is "everyone". The right answer is usually "the people who use it, their managers, and the people who answer the phone". Everyone else receives the notice as noise, and noise is how the organisation learns to ignore the next one.

Choosing the Window With the People Affected

The window is chosen with the people who use the system, not announced to them. And the difference is a ten-minute conversation that prevents the maintenance landing on the one morning it must not. Every organisation has a calendar the desk cannot see. It includes the payroll run, month end, the exam week, the clinic that only opens on Saturdays, and the day the auditors come. Ask the team lead "is there a day in the next three weeks when being without this would be a disaster?" The answer is immediate and specific. A window chosen without asking will, sooner or later, land on the payroll run.

"Out of hours" means the desk's hours, and the desk's hours are not everyone's. Consider a warehouse that runs a night shift or a clinic with a Saturday list. Consider a store that opens at 08:00 or a housing office whose tenants queue from 08:30. Each has a window the desk would call quiet that is the busiest hour of someone's week. Write down, for each system, who uses it and when, and choose the window from that rather than from the desk's rota. A system nobody uses overnight is the easy case. Most systems have somebody.

Build the contingency into the window and tell people the end of the contingency, not the end of the plan. Work estimated at two hours gets a four-hour window. The notice says "unavailable from 06:00 to 10:00" even if the desk expects to finish at 08:00. If it finishes at 08:00, the done message is early and welcome. If it finishes at 09:40, the notice was right. The window also has to leave room for the rollback. If going back to the old state takes an hour, the point of no return is an hour before the window closes. The technician's plan says so. A window that ends at the moment the store opens has a plan for success and nothing else.

What to Expect, in Plain Words

The notice says what will not work, from when to when, in the words the reader uses for the thing. "The tenancy system will not be available from 07:00 on Saturday until 12:00 on Saturday" is the first line, and everything else follows it. If other things stop as a consequence, say those too. The reader does not know that the tenancy system is behind the rent-payment screen. Say: "the rent-payment screen and the repairs lookup also use it and will not work during the window." Then say what will look different afterwards, if anything will. That might be a new login screen, a moved button, a changed name, or a request to set a new password. People are more alarmed by a changed screen nobody mentioned than by an hour of downtime they were told about.

Say what to do before, during and after, in three short lines. Before: save and close work in the system by a time, do not start a long task after it, print anything needed over the window. During: what to use instead, or "please wait; it is not broken". That line is worth including because at 07:05 somebody will see an error and raise a ticket. After: restart, sign in again, and check that the last thing saved is still there. Include who to tell if the system is not back by the end of the window. When there is genuinely nothing the reader has to do, say so in those words: "Nothing you need to do." It is the most welcome sentence in any notice, and it should be true when it is used.

Leave out the reason unless it is the reader's reason. "To apply the supplier's security update" is one clause and sufficient. The version number, the component and the technical motive are the change record's business. The exception is a change made because of something the readers asked for. Then "this fixes the slow search you have been reporting" is the best line in the notice and earns the downtime. Keeping a technical explanation at the reader's level is a skill with its own series in this library. For a maintenance notice the rule is simpler still, because the reader has not asked why, only what and when.

The Subject Line

The subject line is the notice for most readers. And it follows one pattern every time: the service, the word "unavailable", the day and the times, and the one thing to do. "Tenancy system unavailable Saturday 07:00 to 12:00; save and log off Friday" is a subject line that can be read on a phone. It can be sorted in a mailbox and acted on without opening. "Scheduled Maintenance Notification" tells the reader only that a notice exists. It has been used for so many notices about so many systems that it now functions as a filing instruction. It is a subject line that asks to be ignored, and it is granted its wish.

Prefix the reminder and the start and the end so the sequence is visible in the mailbox. Use "Reminder: tenancy system unavailable tomorrow 07:00 to 12:00". Then use "Starting now: tenancy system unavailable until 12:00" and "Done: tenancy system back; sign in again". The prefixes let a reader who has three of them in a row see at a glance which is current. They make the overrun message, when it is needed, visibly different from the plan: "Running late: tenancy system now expected back by 14:00". Use the same pattern for every system, and the organisation learns to read it in a month.

Never put the system's internal name, the ticket number or the change number in the subject. They belong in the change record and, if the desk wants them, at the foot of the notice. A subject line that begins "CHG-6641:" has used its first nine characters on something that means nothing to the reader. On a phone those are a quarter of the characters available. The subject is for the reader. The number is for the desk, and the desk already knows it.

Where the Notice Goes, and How Long It Stays

The advance notice goes by e-mail to the people affected and their managers, with the one-line version to whoever answers the phone. And the planned-maintenance line goes onto the status page the same day. The reminder goes by the same route plus the chat channel. It also goes on a sheet on the device or the door for anyone who works in shifts and reads neither. The starting-now line goes wherever the affected people are looking at that minute. The channels and the matrix that chooses them are in Choosing the Channels for Outage Messages. Planned work uses the same doors, with more notice.

The status page carries the planned maintenance from the advance notice until the done message. It is where the person who finds the system down on Saturday morning looks before phoning. A line that says "tenancy system: Saturday 07:00 to 12:00, planned; not usable during the window" turns a Saturday call into a glance. It is the one entry on the page that can be written a week in advance. Keep it apart from current incidents, and remove it with the done message. The page's layout and its states are in the status page article of this series.

Raise the maintenance as a ticket of its own and send the notices from it. That way, the questions the notices provoke have somewhere to land. On a QuerySolv desk the advance notice, the reminder and the overrun message are public replies on that one ticket. The questions people raise are linked to it. The whole maintenance, including how late it ran, sits in one event history that the next planner can read. Whatever the tool, the principle is the same. A maintenance that lives in six e-mails and a chat thread is one that nobody can reconstruct when the same work is planned again.

The Maintenance That Overruns

Set a decision time inside the window. At that time choose one of three things: finish, roll back, or extend, and tell people which. The decision time is the end of the window minus the time a rollback takes. And it is in the technician's plan before the work starts. At the decision time the technician asks one question: will this be finished and tested before the window closes? If yes, carry on. If no, roll back, and send the rollback message. Only if the work is minutes from done does the third option apply, and only with a message sent before the window closes. The window never ends in silence. Silence at the end of a window is how a planned maintenance becomes an unplanned outage with an audience that was promised otherwise.

The overrun message has four parts and goes out before the original end time, not after. What was promised and what is now expected: "we said 12:00; it will be about 14:00". Why, in one line, without blame: "the data conversion is taking longer than it did in testing". What to do in the meantime, which is usually the same workaround the notice gave, extended. And when the next message comes, at a clock time, even if the answer is "still not done". From this point the maintenance is being communicated like an outage, on the interval described in the cadence article of this series. For the people affected that is what it has become.

If the overrun reaches working hours it did not plan to touch, treat it as a first notice to the people who are arriving. They have not seen the Saturday messages. "The tenancy system is not yet back after the weekend's work. We expect it by 10:30. Use the paper tenancy summary in the meantime. Next update at 09:00." The three lines of The First Notice apply exactly, and so does the five-minute rule. The message is sent before the offices open, not after the first call. A maintenance that overruns into Monday morning with no message waiting for the morning staff has cost the desk the credit of having given notice at all.

The rollback message is the honest one and the one desks most dislike sending. "The work on the tenancy system did not complete in the window. We have put it back the way it was. Everything works as it did on Friday. Nothing has changed, and nothing you need to do. We will reschedule and send a new notice." It is a short message about a long night. And it reads as competence, because pressing on past the window into Monday reads as the opposite. A rollback announced on time is a plan that worked. An overrun announced late is a plan that did not have a second half.

After the Maintenance: The Done Message

The done message is a short all-clear and goes out when the work is finished and tested from a user's seat. For weekend work that means before the first person arrives on Monday. It says the service is back since a time and what changed that people will see. It says what to do now and who to tell if something is odd. "The tenancy system is back since 10:40 Saturday. You will see a new login screen; your username and password are unchanged. Sign in as usual; if the repairs lookup shows an error the first time, close it and open it again. Tell the desk about anything that looks wrong today." Two confirmations before it goes, as for any all-clear, and the status page line comes off with it. The fuller shape of the all-clear, with the lost-work line, is in The All-Clear and the Follow-Up.

Where the change altered something people will see, the done message is also the moment to point at the one-page "what changed" note. That is in the knowledge base or wherever the organisation keeps such things. Three lines with a picture of the new screen save the desk a Monday of "where did the button go" tickets. The done message is the one everyone opens, because it says they can work again. A change that people notice and nobody explained is remembered as a fault. The same change, explained in three lines the morning it appears, is remembered as an update, which is what it was.

Postponing and Cancelling

A postponed or cancelled maintenance gets a message by the same channels, with the same subject pattern, as soon as the decision is made. "Postponed: tenancy system work on Saturday will not go ahead; the system will be available as normal; a new date will follow." The advance notice left standing without this message produces, on Saturday morning, a set of people who stayed away from a system that was working. It also produces a different set who saved and logged off on Friday for no reason. And both sets have learned something about the desk's notices that the desk did not intend to teach. The postponement message is two lines. And it is skipped more often than any other message in this article, because nothing is broken and nothing feels urgent. The notice is still out there. Take it back.

When the new date is set, send a new advance notice rather than a reply to the old one. The people who read the first have forgotten its details and the people who did not never knew them. Update the status page's planned-maintenance line at the same time. A page still showing last Saturday's cancelled window on Monday is believed a little less each time.

A Short War Story: The Till Upgrade at the Harbor Street Store

The Harbor Street store's till software was upgraded on a Saturday morning in a window the desk had set from 05:00 to 08:00. The window ended at the store's opening time. The notice went to the store manager, Rosa, on the Tuesday before, under the subject line "Scheduled Maintenance Notification". The upgrade hit a problem at 06:50. The technician decided to press on rather than roll back. Nobody sent a message, because the technician was busy and the desk was not in until Monday. Rosa had read the Tuesday notice and understood the tills would be back by 08:00. She opened the doors at 08:00 to a Saturday queue and four tills that showed an installer's progress bar. She phoned the desk and got the out-of-hours voicemail. She took cash with a calculator and a notebook until the tills came back at 09:20. The review counted eighty minutes of Saturday trade at one register instead of four and a queue that walked. It also recorded a store manager who said, reasonably, that she would have planned a late opening if anyone had told her at 07:00. The desk changed two things. The window for anything touching a store now ends ninety minutes before opening. The technician's plan also has a decision time. At that time an overrun message goes to the store manager's mobile before the window closes, whoever is on. A maintenance window that ends at the moment the doors open is not a window. It is a bet.

The Maintenance Notice

The template below is the advance notice, the reminder, the starting-now line, the overrun message, the rollback message and the done message. It includes the subject-line pattern for each. Fill the blanks, delete nothing else, and keep the plain words outside them. The advance notice should take five minutes to write from the change record. The others take one or two each on the day. That is the point of having them ready, because the day is the only time there is no time to compose them.

PLANNED-MAINTENANCE NOTICES — ONE SET
Change record: ________   Owner: ____________   Decision time inside the window: __:__

1. ADVANCE NOTICE (five to ten working days before; two or three for one team)
Subject: ____________________ unavailable ________ (day) __:__ to __:__ ; ____________ (what to do)

____________________ (the service, in the users' words) will not be available
from __:__ on ________ until __:__ on ________.
Also affected: ____________________ (other things that depend on it, or "nothing else").

Before:  save and close your work in ____________________ by __:__ on ________;
         do not start ____________________ after that time.
During:  ____________________ (what to use instead), or "please wait; it is not broken".
After:   ____________________ (sign in again, restart, check your last saved item).
What will look different afterwards: ____________________ (or "nothing").
Why, in one line: ____________________.
If it is not back by __:__, tell the desk: ____________ (address / extension).
-- ____________, help desk

2. REMINDER (the working day before, or the morning of an evening window)
Subject: Reminder: ____________________ unavailable tomorrow __:__ to __:__ ; ____________
  The same facts as the advance notice, shorter. The before line first.

3. STARTING NOW (only if any part is in working hours)
Subject: Starting now: ____________________ unavailable until __:__
  ____________________ is going down now for planned work. Back by __:__.
  Meanwhile: ____________________. Please do not raise tickets about it.

4. RUNNING LATE (sent BEFORE the original end time, never after)
Subject: Running late: ____________________ now expected back by __:__
  We said __:__; it will now be about __:__.
  Why, in one line: ____________________.
  Meanwhile: ____________________ (the workaround, extended).
  Next update at __:__, whether or not it is finished.

5. ROLLED BACK (sent before the window closes, if the work will not finish)
Subject: ____________________ back as it was; work postponed
  The work did not complete in the window and has been reversed.
  Everything works as it did before. Nothing has changed; nothing to do.
  A new notice will follow with a new date.

6. DONE (after the technician confirms AND one user confirms from their seat)
Subject: Done: ____________________ back ; ____________ (what to do)
  ____________________ is back since __:__.
  What changed: ____________________ (or: nothing visible).
  Do this now: ____________________.
  If anything looks wrong today, tell the desk: ____________.

CHECK BEFORE SENDING ANY OF THEM
  [ ] Service named in the users' words; no internal names or numbers in the subject
  [ ] The window includes contingency and rollback time; the decision time is set
  [ ] The window was checked against the business calendar with the team lead
  [ ] Sent to the people affected, their managers and reception; not to everyone
  [ ] Status page planned-maintenance line added, and removed with the done message

Owen rewrote Ashgrove's next notice in the pattern above. Its subject line was "Tenancy system unavailable Saturday 07:00 to 14:00; save and log off Friday". The window had three hours of contingency. And the reminder went on Friday at 14:00 with the before line first. The work finished at 11:10. The done message went at 11:25 after a housing officer on the Saturday rota had looked up a tenant. On Monday morning the desk took one call about it. An officer wanted to know whether the new login screen was supposed to look like that. It was. The done message had said so, and she had read it, which Owen regards as the whole result.

Frequently Asked Questions