Skip to main content

Scheduled maintenance email templates: telling customers about planned downtime

Six maintenance notification emails for a software product, from the advance notice to the all-done. Each one gives the date, the time with its time zone, how long it lasts and exactly what will not work.

The templates

Each one copies with its subject line. The parts in brackets are the parts to change; everything else can go out as written.

Advance notice

Subject: Planned maintenance on [date]: [Product] unavailable for [duration]

Hi [Name], [Product] will be down for planned maintenance on [day and date], from [start time] to [end time, time zone]. That is [the same window in a second time zone, if many of your customers are elsewhere]. While it is down: [what will not work, for example: you will not be able to sign in or sync]. [What still works, for example: the app keeps working offline, and anything you change will sync once it is back.] Why: [one plain sentence, for example: I am moving to a faster database, and everything has to pause while the data is copied]. There is nothing you need to do. [If you have one: The status page at link will show progress on the day.] If that window is a bad time for you, reply and tell me. I cannot always move it, but I would rather know. [Your name]
Reminder, the day before

Subject: Reminder: [Product] maintenance tomorrow, [start time, time zone]

Hi [Name], A reminder that [Product] will be down for maintenance tomorrow, [day and date], from [start time] to [end time, time zone]. During that window, [what will not work]. [If there is something worth doing first: If you need anything exported or sent before then, today is the day to do it.] I will email again when it is done. [Your name]
Maintenance running over

Subject: Maintenance update: [Product] is taking longer than planned

Hi [Name], The maintenance on [Product] is taking longer than planned. It was due to finish at [end time, time zone], and it is not done yet. What is happening: [one honest sentence, for example: copying the data is slower than it was in testing, and I would rather let it finish than cut it short]. Until it is done, [Product] is still [unavailable / read-only], which means [what that means for them]. [Only if you know it for certain: Your data is safe; nothing has been lost.] I will send the next update by [time and time zone], or sooner if it finishes before then. Sorry for the extra wait. [Your name]
Done, everything is back

Subject: Done: [Product] maintenance is complete

Hi [Name], The maintenance is done, and [Product] has been back to normal since [time and time zone]. [What changed for them, if anything, for example: Sync should feel quicker. / Nothing looks different; the changes are all underneath.] [Anything to do: You may need to sign in again. / Nothing to do on your side.] If something is not working the way it did before, reply to this email and I will look at it straight away. Thank you for bearing with it. [Your name]
One line, for an in-app banner or a short email

Subject: [Product] maintenance: [date], [start time] to [end time, time zone]

[Product] will be unavailable on [date] from [start time] to [end time, time zone] for planned maintenance. [What will not work, in a few words.] Details: [link]
Customers need to update the app first

Subject: Action needed before [date]: update [Product] to [version number]

Hi [Name], On [date], I am making a change to the [Product] servers that older versions of the app will not work with. To keep everything working, please update to [version number] or later before then. To update: [open Product and choose Check for Updates / download it from link]. Your data and settings stay as they are. If you do not update in time: [exactly what happens, for example: sync stops on that device until you do, and nothing already on it is lost]. The server change itself happens on [date], from [start time] to [end time, time zone], and [Product] will be [unavailable / read-only] during that window. If you cannot update for some reason (an older operating system, a work machine you do not control), reply and tell me which version you are on, and I will tell you your options. [Your name]

If maintenance turns into an unplanned outage, switch to the service outage email templates: the job changes from announcing a window to keeping a promise about the next update.

Subject lines that work unopened

Put the date, and ideally the window, in the subject. A maintenance email is one people glance at and file, so a subject that carries the facts does its job even when nobody opens it. “An important update about our service” does not.

  • Planned maintenance on [date]: [Product] unavailable for [duration]
  • Scheduled downtime: [date], [start time] to [end time, time zone]
  • Reminder: [Product] maintenance tomorrow, [start time, time zone]
  • Maintenance update: taking longer than planned
  • Done: [Product] maintenance is complete
  • Action needed before [date]: update [Product]

What makes a maintenance email land

  • The time zone, every time. “2am” means a different hour to every customer who reads it. Give the zone, and a second one if many customers are somewhere else.
  • What will not work, specifically. “Sign-in and sync will be unavailable; the app keeps working offline” lets people plan. “Some features may be affected” makes them guess, and guessing is how you get the support email on the day.
  • A window you can meet, with slack. Announce the duration you are confident of, not the one you hope for. Finishing early is pleasant; running over needs another email.
  • If they have to act, say so in the subject. An update requirement buried in the third paragraph is the one that turns into a queue of “it stopped working” emails the morning after.
  • Send the done email. People who planned around the window want to know they can stop. It is also where problems surface: “something looks different” replies arrive in answer to it, while the change is fresh.

The notice goes out once. The questions come back one at a time

Moorline does not send maintenance notices; your email tool or status page does that. It is for what comes back. A notice brings a handful of replies over the following week: can you move it, will I lose anything, does the offline app still work, I am on an old version and cannot update. And on the day, someone who never read it writes in to ask why nothing works.

Each is a quick answer, but the ones that need a follow-up (“let me check whether your version is affected”) are the ones that slip. Moorline keeps every conversation on your list until the work is handled and the customer has been told, and one where you are waiting on them comes back to you rather than disappearing. The answers you give ten times belong in snippets, one shortcut away (⌘;). The rest of the routine is in the guide to customer support for solo founders.

Questions people ask

How far in advance should I send a scheduled maintenance email?

For a short window at a quiet hour, a few days is usually enough. For longer downtime, or anything that needs customers to act first, give a week or more, and send a reminder the day before. If your terms or a contract with a business customer promise a notice period, that sets the minimum.

What should a downtime notification email include?

The date, the start and end time with a time zone, what will not work, what still works, whether customers need to do anything beforehand, and where to check on the day. One sentence on why is plenty; the reason matters much less to the reader than the window.

What is the best time to schedule maintenance?

When the fewest of your customers are using the product, which is not always the middle of your own night. If they are spread across time zones, look at when usage is actually lowest. For anything customers use for billing or invoicing, avoid the last and first days of the month.

Do I need to email customers about every maintenance window?

No. If nothing visible changes for them (no downtime, no sign-out, nothing to install), there is nothing to tell them. Email when they will notice, and use a status page or an in-app banner for short windows at quiet hours.

What should I do if maintenance runs over?

Tell customers before the announced end time passes, not after. Say it is taking longer, what is still unavailable, and when the next update will come, and do not name a new finish time unless you are confident of it. From that point it is an outage in everything but name, and it deserves the same care.