A good maintenance window notice tells visitors four things in the first line: what will be unavailable, when, for how long, and what to do instead. Write it as a short, dated, timezone-stamped statement — "The customer portal will be offline Sunday 16 November, 02:00–04:00 UTC, while we upgrade the database.
Orders placed before 01:45 will process normally." — then publish it where the affected people will actually look. Everything else is refinement: choosing the channel, deciding whether to show a holding page or a banner, and making sure search engines and uptime monitors read the outage as temporary rather than permanent. The notice itself is a writing task; the way you serve it is a technical one, and getting the second wrong can undo a perfectly clear message.
Table of Contents
- The four facts every notice needs
- Advance notice, live notice, and the all-clear
- Serving the notice without hurting your site
- WordPress and Drupal specifics
- A reusable template and the words to avoid
- Checking the notice before the window opens
- Frequently Asked Questions
The four facts every notice needs
Start with the service name, not the work. Visitors do not care that you are migrating to PHP 8.4; they care whether checkout works. Lead with the user-facing thing that stops — the shop, the login, the booking form, the whole site — and name it the way your own navigation names it. Then give a start time, an end time, and a timezone.
A window with only a start time reads as indefinite, and "tonight" means nothing to someone two continents away. Prefer an absolute date plus a timezone abbreviation or UTC offset, and add a duration if the window is short, since "02:00–04:00 UTC (2 hours)" is faster to parse than doing the subtraction. Close with the instruction. Most notices need exactly one: come back after 04:00, use the phone line, save your draft before 01:55, or nothing at all if nothing is required. If data loss is possible — an in-progress form, a cart, an unsaved document — say so explicitly and early, because that is the only part of the notice that can cost the reader something.
Advance notice, live notice, and the all-clear
These are three different pieces of writing, and teams usually only write the second. The advance notice goes out before the window — by email, dashboard banner, or a pinned post — and its job is to let people reschedule. Lead time should match how much the outage disrupts: a few hours is fine for a brochure site, while anything transactional deserves several days. The live notice is what visitors hit during the window.
It is short, calm, and repeats the end time, because someone arriving at 03:30 has not seen your email. Give it a human page: the service name, the window, the expected return, and a link or address that still works — a status page on separate infrastructure, or a support email. The all-clear is the cheapest trust you will ever buy. One line confirming the work finished, the time it finished, and any follow-up a user must take closes the loop and stops the "is it still down?" tickets. If the window overran, say by how much; a specific overrun sounds like competence, while silence sounds like you never noticed.
Serving the notice without hurting your site
The technical half matters because a maintenance page returning a normal 200 OK tells crawlers that your "We'll be back soon" copy is the page's real content. The correct status for a planned outage is HTTP 503 Service Unavailable, optionally with a `Retry-After` header giving either a number of seconds or an HTTP-format date. Google's own guidance on site downtime has long recommended 503 for temporary unavailability, and warns against serving a 404 or a 200 for maintenance.
Keep the maintenance page on the same URLs rather than redirecting everything to `/maintenance`. A site-wide 302 to one page costs you nothing permanently, but it is more work to unwind and it collapses every URL into one for the duration. Serving 503 in place, from the same address, is simpler and reverses cleanly. Two practical cautions:.
- Short windows are usually safe for search. A multi-day outage is a different risk category, and if work will run for days, a staged or read-only mode beats a blanket 503.
- Tell your uptime monitoring and your on-call rota about the window first, or your own alerting will page someone about an outage you scheduled.
WordPress and Drupal specifics
WordPress enters maintenance mode by itself during core, theme, and plugin updates. It writes a `.maintenance` file to the site root, serves a terse default message, and deletes the file when the update completes. If an update dies partway, that file can be left behind and the site stays stuck — deleting `.maintenance` over SFTP or the file manager is the standard fix. The default message is not something to rely on for a planned window; it is a byproduct, and it carries none of your four facts.
For a real planned window on WordPress you have three options, in rough order of effort: a maintenance-mode plugin, a small `wp_maintenance_mode`-style snippet or must-use plugin that serves your own 503 page, or a notice handled at the host or CDN layer so visitors never reach PHP at all. The last is the most robust, since it keeps working while the application itself is down — which is precisely when the notice matters. Drupal ships the equivalent as a core feature. Maintenance mode is a setting (in recent versions, under Development → Maintenance mode) with an editable maintenance message, and users with the "Access site in maintenance mode" permission can still browse while everyone else sees the notice. That permission is what lets you verify the deployment before you let the public back in.
A reusable template and the words to avoid
Keep a filled-in skeleton in your runbook so nobody drafts under pressure at 01:50. Something like: "[Service] will be unavailable [day, date], [start]–[end] [timezone], for [one-clause reason]. [What the visitor should do]. Updates: [status page or contact]." Avoid the three phrasings that cause the most follow-up. "Down for maintenance" with no end time is the worst, because it is indistinguishable from an unplanned outage.
"We apologise for any inconvenience this may cause" is filler that pushes the end time further down the page. And "brief" or "scheduled maintenance" without numbers tells a reader nothing they can act on. Resist the urge to name the technology. "Database upgrade" or "security updates" is enough reason for a public page; the specific versions, vendors, and error conditions belong in your internal change record, not on a page a stranger reads. The exception is a window driven by something your users already know about — a payment provider migration, say — where naming it answers the question before it is asked.
Checking the notice before the window opens
Test the notice the way a visitor meets it, not the way you built it. The ten-minute pass that catches most problems: One more thing worth doing before you flip the switch: write the all-clear now, while you are calm, and leave it in a draft. The window is the single worst moment to compose a sentence you will be judged on.
- Load the site in a private window and on a phone, and confirm the end time is visible without scrolling.
- Run `curl -I https://yoursite.example` and confirm the status line says 503, not 200 or 404.
- Confirm your status page and support address are hosted somewhere the outage does not touch.
- Have someone outside the project read the notice cold and tell you when the site returns. If they hesitate, the time formatting is wrong.
- Check the timezone against the audience you actually have, not the one the office sits in.
Frequently Asked Questions
How far in advance should I announce a maintenance window?
Match the lead time to the disruption. A few hours suffices for an informational site; anything involving payments, bookings, or logins deserves several days so users can reschedule around it.
Does a maintenance page hurt my search rankings?
A short window served as HTTP 503 is generally handled as temporary unavailability rather than a content change. The real risk is serving a 200 or a 404, which invites crawlers to treat the maintenance text as the page's actual content or the URL as gone.
Why is my WordPress site stuck showing "briefly unavailable for scheduled maintenance"?
An update died before WordPress removed its `.maintenance` flag file from the site root. Delete that file over SFTP or your host's file manager, then re-run the update.
Should the notice say what we are fixing?
A one-clause reason — "security updates", "database upgrade" — is enough. Specific versions and error details belong in your internal change log, not on a public page.
