How to properly announce scheduled network maintenance to your users

Published by Kimberley Parsons Trommler
Last updated on January 23, 2024 • 14 minute read

Every system administrator, at some point, needs to take an important service offline temporarily, for scheduled maintenance or for upgrades. This article provides guidance on what to include in a downtime announcement and how to communicate upcoming maintenance windows to your users. Our experience as a company with 300 employees spread around the world is that it's critical to communicate very thoroughly to avoid confusion and resulting loss of productivity.

how to properly announce scheduled network maintenance to your users

Scheduling Your Communication

If at all possible, give your users at least a few days' notice for planned downtime. This gives them enough time to prepare themselves and to mitigate the effect on their work environment. The larger the impact on users, the longer the lead time needs to be. Server maintenance on important systems should be communicated at least a week ahead of time; minor ones a day or two.

In most cases, a single email is not enough. Depending on the expected impact, send one a week ahead of time, one a few days ahead of time, one the day before, and one the day of the planned downtime. Not all of your users will remember a single notice, so use multiple notices to keep reminding them as the scheduled time gets closer.

And don't forget to follow up after the systems are back online. Let your users know that the downtime is over and they can work again.

Scheduling Your Maintenance Windows

For scheduled downtime, select a time that is the least inconvenient for the majority of your users. If your users are worldwide, you're always going to affect some of them. But if there are time zones with significantly fewer users than others, plan your maintenance around those user counts. Admittedly, this usually means it will be a very inconvenient time for the IT administrators. But it's better for the company as whole to inconvenience a few administrators rather than large parts of the business.

What Channels to Use

If possible, communicate the upcoming downtime using multiple channels. Email is the main medium used, but you can also communicate via social media, web pages, internal communication methods (eg. Microsoft Teams) or on the application's start page, as appropriate. The best medium will depend on whether you need to reach internal users, existing customers, or the general public.

For applications or certain software, place a notice about upcoming downtime on the login page or main start page a few days ahead of time, so that users are able to plan their work around the downtime. Don't simply put a notice in a Web application that the application is currently unavailable - give the users enough notice to mitigate the effect on their work environment.

If the affected application is a smartphone app, you can add in-app alerts or push notifications.

If you offer services over the Internet and it's these services that will be down, use a 3^rd party online status website such as StatusPage or Constant Status.

Important Information to Include in Your Message

Like we all learned in school, you must be sure to include answers to all of the "W" questions: Who? What? When? Where? Why? And hoW?

Type of Notification and Criticality

How important is this downtime? How severe is the outage? Is this notice about a critical system, or only informational?
Is this planned or unplanned downtime? Scheduled maintenance? Replacement of older systems? Deployment of new systems? Update of existing systems and tools?
Let users know what new features or improvements (e.g. better network security, less problems or errors) this upgrade will bring. Knowing that they will benefit long-term from the downtime increases user acceptance.

Reach

What parts of the infrastructure are affected? Is it only affecting certain departments, buildings or locations?
What customers or users are affected?
What services are affected?
What is NOT affected?
What users can/cannot do during this time. For example, can they send emails internally but not externally?
What will happen if they attempt something that doesn't work? For example, if they send email, will the email be lost/deleted, or will it be sent after the downtime?

The Exact Start Time And Estimated End Time

If you can't estimate the end time of the outage, then state when you will send the next update.
If your users/customers are in multiple time zones, be sure to include start/end times for each time zone. If including all relevant time zones would be impractical, be sure to indicate which time zone you're using in your message.
Be very clear on what date and time formats you are using, as this varies from culture to culture. "08.06.2017", for example, could mean August 6^th or June 8^th.
When calculating the estimated duration of the downtime, be sure to leave yourself a generous buffer. You need to be pessimistic here, not optimistic (remember Murphy's Law!). Allow your users to be pleasantly surprised that you're back online earlier than planned if things go well.

An Overview of What You're Doing

Describe what you're currently doing to address the outage or problem
If this is planned downtime for upgrades, you can let users know what new features or improvements this upgrade will bring. Knowing that they will benefit long-term from the downtime increases user acceptance

User Action Required

If the users need to take action, include very clear instructions on what to do (e.g. make a backup, upgrade your hardware, or restart your computer)
Give a contact name/number to provide assistance.

Closing Info

Assure users that the situation is under control.
Apologize for the inconvenience (even if it isn't your fault).
Include contact information or methods to receive additional information or updates.
Include contact information to report issues that occur during or after the update.

Optional Details To Include:

If the email has been sent to your entire staff, a notice like this one will prevent unnecessary forwarding: "Please note that this email has been sent to all staff and does not need to be forwarded."
"Add to calendar" options for scheduled downtime that could affect their work (e.g. iCal entries for the hours when the email servers will be down).
If you're using a status website, include the link to the site.
If you're communicating via social media include instructions on how to follow the status on that social media (e.g. what hashtags or usernames to follow).

Style of writing

Keep it clear and concise. If your email isn't short and to-the-point, it may get deleted before it's read. Structure and format the text to make the most important details easy to find.

Tailor the level of technical detail to your audience. If they're mainly non-technical, an overview is plenty. Don't overwhelm them with technical details they won't understand, but do give them enough information to assuage their concerns.

On the other hand, if your users are well-versed technically, they'll appreciate knowing the details and will thank you for providing detailed technical information. GitLab's transparency when they accidentally lost some production data, including live-streaming the recovery, was well-received by their deeply technical user base.

If you have a mix of technical and non-technical people, give only an overview of the details and provide a link to more details for those who are interested.

If your organization's culture permits, feel free to take a light-hearted approach and to use humor. Your users are humans too! Smashing Magazine posted some great examples on their site.

Stay polite and professional, and stick to the facts. Do not blame others for the downtime (even if others are responsible) and don't disparage vendors or other departments. Assume your message will be seen by senior management and the other departments or vendors - discussions about root cause should be discussed directly with the parties involved, not in an email to all users.

And if you have to, err on the side of being apologetic, even if it isn't your fault. You're providing a service, and you need to interrupt this service, for a multitude of reasons. Even though you've give them warning, network maintenance is an inconvenience for your users, so feel free to acknowledge that.