Planned maintenance needs a short sequence of messages, not one: an announcement a week ahead, a reminder the day before, a "starting now" note, a "complete" note, and a ready-made update for when the work runs over. Each one gives the window in the customer's time zone, says exactly what will be affected, and says where to watch for updates.
Below are paste-ready versions for email, the status page and an in-app banner.
Last verified: 4 November 2026.
What every maintenance notice needs
Five things, in this order:
- What's affected, named the way customers know it ("the API and webhooks", not "db-primary-2").
- When, as a start and end time with the time zone, plus the same window in UTC if your customers are spread out.
- What they'll notice: full downtime, read-only, slower responses, or nothing visible.
- What they need to do, if anything. Usually nothing; say so.
- Where updates will appear: your status page URL.
Leave out the why unless it helps the customer. "Upgrading our database" is enough. A paragraph on the migration plan isn't.
When to send each message
| Message | When | Channel |
|---|---|---|
| Announcement | 5–7 days before (2 weeks if customers need to act) | Email to affected accounts, status page |
| Reminder | 24 hours before | Status page, in-app banner, email only for disruptive work |
| Starting | When the work begins | Status page |
| Extended (if needed) | Before the scheduled end, not after | Status page, plus email if the overrun is long |
| Complete | When the work is verified | Status page, email only if you emailed the announcement |
These timings are our suggestion, not an industry rule. Shorten them for low-impact work and lengthen them for anything that changes how customers integrate with you.
Templates
Replace anything in brackets.
1. Announcement
Email subject: Scheduled maintenance: [component], [day date], [start]–[end] [time zone]
Hi [first name],
We're carrying out planned maintenance on [component] on [day date] from [start] to [end] [time zone] ([start]–[end] UTC).
What you'll notice: [component] will be [unavailable / read-only / slower than usual] for up to [duration]. [Everything else, including X and Y, stays available.]
What you need to do: nothing. [Or: please pause any scheduled imports during the window.]
We'll post updates at [status page URL] when the work starts and when it's done.
[Name], [company]
Status page:
Scheduled: [component] maintenance
[Day date], [start]–[end] [time zone]. [Component] will be [unavailable / read-only] for up to [duration]. No action needed. We'll update this page when the work starts and finishes.
2. Reminder
In-app banner:
Planned maintenance [tomorrow / today] from [start] to [end] [time zone]: [component] will be [unavailable / read-only]. [Details]([status page URL])
Status page (edit the scheduled notice instead of posting a new one):
Reminder: this maintenance starts in 24 hours.
3. Starting
In progress: [component] maintenance
We've started the planned work on [component]. It's [unavailable / read-only] until [end] [time zone]. We'll post here when it's complete.
4. Extended
This is the one most template lists skip. Post it before the scheduled end, with a new time you're confident of, and say what still works.
Update: maintenance is taking longer than planned
The work on [component] needs more time. We now expect to finish by [new end] [time zone]. [Component] stays [unavailable / read-only] until then; [everything else] is working normally. Next update by [time], or sooner if we finish.
If you're not confident of a new end time, say when the next update will come instead:
We don't have a reliable finish time yet. We'll post an update by [time] [time zone].
If the overrun turns into an unplanned problem, such as something failing that wasn't part of the work, stop calling it maintenance and open an incident. Customers will forgive a planned job running long. They won't like finding out later that it was an outage all along. Our incident communication templates cover that switch.
5. Complete
Status page:
Completed: [component] maintenance
The planned work on [component] finished at [time] [time zone] and everything is working normally. If anything looks wrong, reply to [support address] and we'll look straight away.
Email (only if you emailed the announcement):
Subject: Maintenance complete: [component]
The planned maintenance on [component] finished at [time] [time zone]. Everything is running normally. Thanks for your patience. If you notice anything odd, just reply to this email.
Common mistakes
- A time with no time zone. "02:00" means three different things to three customers. Give the zone and UTC.
- Announcing to everyone. If only API users are affected, email API users. Over-notifying trains people to ignore you.
- Posting "extended" after the window has already ended. By then customers have noticed. Post it while there's still time left on the clock.
- Alerting your own team about planned downtime. If your monitoring pages someone for a service you took down on purpose, the next real alert gets taken less seriously.
- No "complete" message. Without one, customers are left wondering whether it's safe to use the product again.
How this works in StayUpfront
In StayUpfront you schedule the window once, with the affected components and start time, and it shows on your status page ahead of time, so planned work never reads as an outage. It also lands in the status page feed that customers can follow.
The window can close itself at the scheduled end, or stay open until you close it by hand. That suits the extended case: when you can't trust the clock, leave it open. Alert suppression is per window and per component, so only the parts under maintenance go quiet and a real outage elsewhere still alerts.
StayUpfront doesn't send maintenance emails for you, so send the announcement and any long-overrun email from the tool you already use for customer email.
If you're choosing a support tool that keeps the status page, incidents and tickets together, our comparison for small B2B SaaS teams sets out where we fit and where others fit better.
Common questions
How far in advance should I announce scheduled maintenance?
Five to seven days for routine work, and two weeks or more if customers need to change something on their side. Follow up with a reminder 24 hours before.
Should I email every customer about maintenance?
No. Email the accounts that use the affected part of the product, and put the notice on your status page for everyone else.
What should a maintenance notification include?
What's affected, the start and end time with a time zone, what customers will notice, whether they need to do anything, and where updates will appear.
What do I say when maintenance overruns?
Post before the scheduled end, give a new finish time or a time for the next update, and say what still works. If something unplanned broke, open an incident instead.
What's the best time of day for SaaS maintenance?
When your own usage data says the fewest customers are active, and when someone who can fix things is awake. For a B2B product, that's often early morning or a weekend in your main customers' time zone.