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.
Subject: Planned maintenance on [date]: [Product] unavailable for [duration]
Subject: Reminder: [Product] maintenance tomorrow, [start time, time zone]
Subject: Maintenance update: [Product] is taking longer than planned
Subject: Done: [Product] maintenance is complete
Subject: [Product] maintenance: [date], [start time] to [end time, time zone]
Subject: Action needed before [date]: update [Product] to [version number]
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.