Maintenance Messages: Templates, and When to Send Them

A maintenance message tells customers that a service will be, is, or was unavailable for planned work. A useful one names the affected component, gives an exact window with a timezone, says what users should expect and whether they need to act, and states where the next update will appear. Most published notices do none of this: in a sample of 841 real status-page updates, 64.6% were unedited default text.

Key takeaways

• Of 841 maintenance updates across six public status pages, 543 (64.6%) were the tool's default wording, unmodified.
• Advance notice varies enormously between companies: a median of 13.9 days at one, 1.99 days at another.
• Always give a timezone, and give the right one. The most dangerous timezone error is the one that is internally consistent and still wrong.
• Statuspage has no cancelled state, so cancelled maintenance gets filed as completed. Say it in the text, because the status field cannot.
• Serve the page itself as 503, never 200, and never let robots.txt return an error during the window.

What the published notices actually look like

Before writing any advice, we pulled the maintenance history from six public Statuspage-hosted status pages and read every update: 841 in total. The result is the argument for this article. 543 of them, 64.6%, were the platform's default text with nothing changed.

Every one of the six pages belongs to a company with a competent operations team. This is not incompetence, it is what happens when writing the notice is the last step before a maintenance window at 2am and the tool has helpfully pre-filled the field. The cost is that a customer reading "Scheduled maintenance is currently in progress. We will provide updates as necessary." learns nothing they could not infer from the fact that a notice exists.

What a maintenance message has to contain

Six things. Anything beyond them is optional, and the first four are the ones boilerplate always omits.

• What is affected, and what is not. "The API will be unavailable" is very different from "the dashboard will be read-only". Naming what keeps working prevents most support tickets.
• The window, with a timezone. Start and end, with an offset. See the timezone section below, because this is where notices most often go wrong.
• Expected impact. Will requests fail, or queue, or be slow? Will in-flight work be lost? This is the question the reader actually has.
• Whether they need to do anything. Usually the answer is no, and saying so explicitly is worth more than the rest of the notice combined.
• Where the next update will appear. Commit to a place and a time.
• Who it is from. Obvious on a status page, easy to forget in an email.

The templates

Eight notices covering the full lifecycle, written to be edited rather than pasted blind. Square brackets mark what you must replace. These are customer-facing; internal staff notices have a different register and usually a different channel.

1. Advance notice

Scheduled maintenance: [component], [day] [date], [start]-[end] [TZ offset]

We will be performing planned maintenance on [component] on
[weekday, full date] from [HH:MM] to [HH:MM] [UTC+/-NN].

What to expect
  - [component] will be unavailable for up to [duration].
  - [what keeps working] is not affected and will remain available.
  - [in-flight requests will queue and complete afterwards / will fail
    and should be retried].

Do I need to do anything?
  No action is required. [Or: if you run [integration], pause it for
  the window and resume afterwards.]

We will post updates here when the work starts and when it finishes.

2. Reminder

Reminder: [component] maintenance starts in [24 hours / 1 hour]

The planned maintenance announced on [date] begins at
[HH:MM] [UTC+/-NN] on [date].

[component] will be unavailable for up to [duration].
[what keeps working] is not affected.

Nothing has changed since the original notice.

3. Starting now

Maintenance has started

Work on [component] began at [HH:MM] [UTC+/-NN] as scheduled.
[component] is now unavailable. We expect to finish by
[HH:MM] [UTC+/-NN].

Next update: [HH:MM] [UTC+/-NN], or sooner if anything changes.

4. Progress update

This is the one that is boilerplate 206 times in our sample. It is worth thirty seconds of writing because it is the notice people refresh for.

Update: [what has actually happened]

[Two of the three database nodes have been upgraded. The third is
in progress.] We remain on track to finish by [HH:MM] [UTC+/-NN].

[component] is still unavailable. [what keeps working] is unaffected.

Next update: [HH:MM] [UTC+/-NN].

5. Completed

Maintenance complete

Work on [component] finished at [HH:MM] [UTC+/-NN]. We have
confirmed that [specific check: the API is returning 200s across all
regions / queues have drained / dashboards are loading].

[component] is fully available.

If you are still seeing problems, [how to reach support].

6. Overrunning

Post this before the original end time passes, not after. A window that quietly runs over is how planned maintenance turns into a perceived outage.

Maintenance is running longer than planned

The window for [component] was due to end at [HH:MM] [UTC+/-NN].
[What is taking longer, in one honest sentence.]

Revised estimate: [HH:MM] [UTC+/-NN].
[component] remains unavailable. [what keeps working] is unaffected.

Next update: [HH:MM] [UTC+/-NN]. We will keep updating on that
interval until this is resolved.

7. Cancelled or rescheduled

CANCELLED: [component] maintenance, [original date]

The maintenance scheduled for [date] at [HH:MM] [UTC+/-NN] will
not go ahead. [One sentence on why.]

No impact to [component] is expected. You can disregard the
earlier notice.

[We will announce a new window at least [N] days in advance. /
This work is no longer required.]

8. Emergency maintenance

Emergency maintenance: [component]

We are performing unplanned urgent maintenance on [component],
starting [HH:MM] [UTC+/-NN]. [One sentence on why it could not
wait, without disclosing anything security-sensitive.]

[component] will be unavailable for approximately [duration].
[what keeps working] is not affected.

We apologise for the lack of notice. Next update:
[HH:MM] [UTC+/-NN].

How much notice to give

There is no standard, and the spread between companies is far wider than the advice literature suggests. From the same sample of status pages, measuring the gap between when each maintenance was announced and when it started:

Two things stand out. The first is the range: a factor of seven between the most and least advance notice, among companies of comparable seriousness. The second is DigitalOcean's consistency. A median of 1.99 days with an interquartile spread of under an hour is not a habit, it is a policy being executed by automation. Whether two days is enough is a separate question from whether it is deliberate, and being deliberate is the part most teams are missing.

For a starting point rather than a benchmark, Paessler's guidance is to announce maintenance on critical systems at least a week ahead and routine maintenance one to two days ahead. That is a reasonable default. The better approach is to set your own policy, write it into your SLA or support documentation, and then hit it consistently, because a predictable two days beats an erratic two weeks.

(One caveat on our own numbers: a sixth page in the sample had only seven maintenance events, too few to quote a median from, so it is excluded from the table above. The 841-update boilerplate count includes it.)

Timezones, where notices go wrong

A window without a timezone is not a window. But the failure mode worth guarding against is subtler than omission, and we found a live example of it: a notice announcing maintenance "Saturday, April 27th from 4:00PM to 6:00PM PST", with PST repeated in the body.

April 27 falls inside daylight saving time every year, so the correct label was PDT. The notice was internally consistent and uniformly wrong, which is more dangerous than a contradiction, because nothing about it looks like an error to a reviewer. Everyone reading it who converted carefully arrived at the wrong hour.

• Prefer UTC with an explicit offset, or an ISO 8601 profile as specified in RFC 3339. 2026-04-27T16:00:00-07:00 cannot be misread.
• Never use bare abbreviations like PST, CST or IST. PST and PDT are eight months apart in usage, CST is claimed by three different zones, and IST by three more.
• Give the duration as well as the endpoints. "16:00 to 18:00 UTC (2 hours)" survives a reader mis-converting one of the two times.
• Let the status page render local time where the tool supports it, and still print the offset in the text, because the text is what gets copied into emails and Slack.

The status vocabulary, and the state it is missing

Most status-page tools model maintenance as a small state machine. Statuspage uses Scheduled, In Progress, Verifying and Completed, where Verifying means "the scheduled maintenance is complete but you're still verifying that things are back to functioning as expected". That fourth state is the most useful and the least used: in 841 updates we found it four times, on three of six pages, and all four instances were the untouched default string.

More consequentially, there is no cancelled state. We found cancelled maintenance filed under Completed, because that is the only terminal option available. A reader scanning statuses sees a completed maintenance that never happened. Azure's notification vocabulary does model this, with an explicit Canceled state alongside Rescheduled, which covers work that started but could not finish inside its window.

The practical consequence for you is template 7 above: put the cancellation in the title and the first line, because the status field cannot carry it. Do not rely on the state machine to communicate something it has no state for.

One more feature worth knowing if your tool has it: Cachet supports a future "published at" time, and while it is set in the future the maintenance is hidden from both the status page and the public API until that moment. That is an embargo, and it is useful for preparing notices in advance without revealing a change window early. Whichever tool you use, the window belongs on the status page itself rather than only in an email, so a user who arrives mid-window finds the explanation where they are already looking.

Serving the maintenance page itself

The wording is most of the job, but the HTTP layer is where planned maintenance can do lasting damage. Two rules cover nearly all of it.

Return 503, not 200. A maintenance page served with a 200 tells search engines that your holding page is the real content of that URL, and it is eligible to be indexed as such. A 503 says the condition is temporary. It is also not heuristically cacheable, so intermediaries will not hold onto it. The mechanics, including the Retry-After header, are covered in detail on our 503 Service Unavailable page.

Never let robots.txt return an error. This is the one that surprises people. If robots.txt itself returns a 5xx, crawlers stop crawling the entire site for as long as that persists, which RFC 9309 makes a normative requirement. Google documents that "for the first 12 hours, Google stops crawling the site but keeps trying to fetch the robots.txt file", and separately that "a 503 (service unavailable) error results in fairly frequent retrying". A blanket rule that puts every path behind the maintenance responder will catch robots.txt too. Exclude it explicitly.

On duration: John Mueller's guidance, as reported in 2017, was that "roughly hours is fine" and that "if it's weeks then it's not really temporary", with the blunter version being that a site inaccessible for weeks is "an error page, essentially". A normal maintenance window is nowhere near this. It matters for extended migrations. And do not reach for Search Console's temporary removal tool for a maintenance window; Google's own guidance on pausing a business advises against it for closures.

Keep the page itself trivial. Google recommends static HTML and minimising off-page resources for a 503 page, which makes sense: the reason you are serving it is often that the backend is unavailable, so the page must not depend on the backend.

Stop your own monitoring from paging you

The step that gets forgotten until the first time it happens. A planned window will trip every uptime check you have, page whoever is on call, and put a red incident on the status page you just carefully updated. It also corrupts your uptime figures, which matters if you report against an SLA.

Pause or suppress the affected checks for the window, and set the suppression to expire on its own rather than relying on someone remembering to switch it back on. Forgetting to re-enable monitoring after maintenance is a genuine outage-extending failure, and it is more common than forgetting to disable it. If the work is on a subset of infrastructure, suppress only the checks that cover it, so a real unrelated failure during the window still reaches somebody.

Decide in advance whether planned maintenance counts against your published uptime. Both answers are defensible and the choice belongs in your SLA rather than in a spreadsheet after the fact. What is not defensible is deciding after you see the number. The distinction between a planned window and unplanned service degradation is exactly the kind of thing an SLA definition should settle before either happens.

The mistakes worth naming

1. Shipping the default text. Two thirds of real notices do this. It is the cheapest thing on this list to fix.
2. A window with no timezone, or with a bare abbreviation that is ambiguous or seasonally wrong.
3. Announcing what is broken but not what still works. Readers assume the worst, and your support queue absorbs the difference.
4. Apologising instead of informing. "We apologise for any inconvenience" is not a substitute for a sentence about impact.
5. Going quiet mid-window. If you promised an update at a time, post at that time even if the update is "no change".
6. Announcing the overrun after the deadline. Post before the announced end time, while it is still information rather than an excuse.
7. Leaving monitoring suppressed after the window closes.

See how Pulsetic's status pages catches this from the outside, across 15+ locations.