Checked from regions with auto-retry. No single-location false alarms.
All systems operational. Steady pulse across every region.
api.example.com returned no response from all 6 regions. Auto-retry confirmed the outage, then we alerted your team.
api.example.com is back up. The incident is logged to your status page history automatically.
90-day uptime · branded · your domain
Live demo · drive it, no signup needed
A scheduled maintenance notification tells customers, in advance, that a service will be unavailable or degraded during a specific window. A usable one answers six things: what is happening, which services are affected, the exact start and end times with a timezone, what the customer should expect or do, where live updates will appear, and who to contact. Send it at least five business days ahead for anything customer-facing, repeat it 24 hours before, and post it on your status page as well as by email, because the customers who need it most are the ones who missed the email.
Maintenance notices get written in a hurry, usually by whoever is doing the maintenance, an hour before it starts. That is how you end up with a message that says "we will be performing scheduled maintenance" and nothing a customer can act on. The templates below are the ones worth copying, plus the timing rules and the two questions that decide whether anyone reads them.
What to include in a scheduled maintenance notification
Six elements. Anything beyond these is optional, and anything missing one of these generates support tickets.
| Element | What it has to say | How it usually goes wrong |
|---|---|---|
| What is happening | One plain sentence about the work, in terms of its effect rather than its mechanism. | Written for engineers: "migrating the primary cluster to a new availability zone" tells a customer nothing. |
| What is affected | The specific services, and just as importantly, the ones that keep working. | Says "our platform", so every customer assumes everything they use is down. |
| Exact window with a timezone | Start and end, date included, with an explicit timezone and ideally a second one. | "Tonight from 11pm" with no timezone, sent to customers in four countries. |
| Expected impact | Whether the service is fully down, read-only, slower, or fine but unsupported. | Defaults to total unavailability when the real impact was a two minute failover. |
| Where updates will appear | A link to the status page, named as such. | Omitted, so the next hour is spent answering the same question individually. |
| Who to contact | A real address or channel, and what to do if the window overruns. | A no-reply sender, which is the fastest way to turn a routine notice into a complaint. |
The one people skip is the second: naming what still works. If your billing system is going offline but the application is not, saying so halves the volume of worried messages. Support teams that field the same question dozens of times during a window usually end up automating the first reply rather than typing it, which works well precisely because a maintenance window produces one question asked many ways.
Scheduled maintenance notification template for customers
The general purpose version. Fill the brackets and send.
Subject: Scheduled maintenance on [service], [day] [date], [start time] to [end time] [timezone]
Hi [name],
We have scheduled maintenance on [service] for [day, date] from [start time] to [end time] [timezone] ([second timezone equivalent]).
During this window, [affected service] will be [unavailable / read-only / intermittently slow]. [Unaffected service] and [unaffected service] are not affected and will keep working normally.
We are doing this to [plain language reason: improve performance, apply a security update, upgrade the database]. We expect the full window to be [duration], though the work often finishes sooner.
You do not need to do anything to prepare. [Or: if you have a scheduled export running during this window, move it to after [end time].]
Live updates will be posted on our status page at [status page URL] throughout the window. If you have questions, reply to this email or contact us at [address].
Thanks,
[name], [team]
System maintenance notification template for internal users
Internal notices can be shorter and much more specific, because you know exactly who is affected and what they were planning to do.
Subject: [System] unavailable [day] [date], [start] to [end] [timezone]
[System] will be offline for [duration] on [day, date], [start time] to [end time] [timezone], for [reason].
What this means for you: [team] will not be able to [specific task]. [Other team] is unaffected. Anything submitted after [cutoff time] will queue and process once we are back.
If you have a deadline that falls inside this window, tell [owner] before [date] and we will move the work.
Updates in [channel]. Owner: [name].
Outage notification email template for unplanned downtime
A different job. Nobody chose this window, so the message trades detail for speed. Send the first one within fifteen minutes of confirming the problem, even though you will not know the cause yet, because the alternative is silence while customers work out for themselves that something is wrong.
Subject: [Service] is currently unavailable
We are aware that [service] is [unavailable / returning errors / running slowly] as of [time] [timezone]. This started at approximately [time].
[What we know: which function is affected, and what still works.]
Our team is working on it now. We do not yet have an estimated time to resolution, and we will update this page every [30 minutes] until it is resolved, whether or not there is news.
Status page: [URL]
The commitment to update on a fixed cadence "whether or not there is news" is the single most useful line in that template. It converts an open-ended wait into a predictable one, and it stops customers from checking every four minutes. Keep the promise, including the updates that say nothing has changed.
System down notice to a customer who is already asking
When a customer reaches you before your notification does, resist the urge to write something new. Acknowledge, confirm it is not just them, give the same cadence promise, and point at the same status page. The failure mode here is a support agent inventing a resolution time to be reassuring, which creates a second incident when it passes.
How far in advance should you send a maintenance notification?
Five business days for planned customer-facing work, with a reminder 24 hours before and a short note when the window opens. For internal systems, two business days is usually enough. Anything under 24 hours reads as unplanned regardless of what you call it, and enterprise contracts frequently specify a minimum notice period, so check the agreement before you pick a date.
What time should you schedule maintenance?
Pick the hour with the lowest real traffic in your own data rather than the one that feels quiet. For a US business-hours product that is typically late evening or early Sunday morning Eastern, but a tool used by international teams may have no genuinely quiet hour, in which case shorter windows matter more than later ones. Avoid the last business day of the month if you serve finance teams, and avoid Fridays if you would rather not debug a failed migration on a weekend.
Do you have to notify customers of scheduled maintenance?
Contractually, often yes. Most business SLAs exclude planned maintenance from the uptime calculation only if notice was given, within a defined window, through a defined channel. That clause is what turns a notification from a courtesy into a condition, because maintenance you did not announce properly can count against the availability figure you report. It is worth reading your own agreement before assuming an email is sufficient, since some contracts name the status page specifically.
This is also why maintenance windows belong in your uptime record rather than outside it. If you publish an availability number, decide once whether planned maintenance is excluded, write that definition down, and apply it consistently. Our note on SLA monitoring covers how that gets recorded, and the uptime calculator shows what a given window costs against a target if you choose to count it.
Where the notification should actually live
Email alone is not enough, for a mundane reason: the customer who cares most is the one who is mid-task at 11pm and never saw the message. The notice needs a permanent home, published before the window and updated during it, which is what a status page is for. Scheduled maintenance is usually the first thing a team publishes there, because it is the one outage you can write in advance and schedule.
Practical detail worth getting right: post the maintenance to the status page as a scheduled event rather than announcing it in the incident feed. Most status page products distinguish the two, subscribers get a different notification for each, and a planned window filed as an incident makes your history look worse than it was. If you are choosing a tool, we compare the products on status page software and the cost of each, including the monitoring bill underneath the publish-only ones, on status page pricing. If you are building the page itself, how to create a status page covers component naming and the hosting independence question.
After the window closes
Send a short confirmation. Three sentences: the work is done, the service is back as of a specific time, and here is anything a customer needs to know, such as a changed URL or a feature that now behaves differently. Teams routinely skip this, which leaves customers who saw the first email uncertain for the rest of the day.
If the window overran or something broke, say so plainly in that message and give the new expected time rather than quietly extending. A maintenance window that turns into an unplanned outage is worth writing up properly afterwards, and the incident postmortem template is the format for that.
Where to start
Save the three templates above where the person doing the maintenance will find them, agree your notice period once so it stops being a per-window decision, and make sure the status page exists before you need it. The templates take ten minutes to adapt. The part that has to be in place beforehand is somewhere public to put them, and monitoring that will tell you honestly whether the service actually came back when you said it did.
Know your site is down before your customers do
Start monitoring your sites, APIs and services from six regions, with alerts by Slack, email, SMS and webhook and a branded status page. Transparent, flat pricing per monitor.