Announcing scheduled maintenance badly can do more damage than the maintenance window itself. A vague email that says “your service may be affected” sends worried customers to support, while a well-written scheduled maintenance announcement barely gets noticed, and that’s the goal. This article covers when to announce, what to write, which channels to use, and how to keep your uptime monitoring honest while the work happens.
Why the Wording Matters More Than the Downtime
Most users don’t mind a 30-minute window at 02:00 UTC on a Sunday. They mind not knowing about it. A database migration announced with a clear time, a clear scope, and a clear “what you need to do” (usually nothing) causes almost no friction.
Users react to uncertainty. “Possible disruption to services” sounds like something might break. “Checkout will be unavailable for up to 20 minutes, from 02:00 to 02:20 UTC on Sunday 15 November; browsing and accounts are not affected” sounds like a plan.
A good notice answers four questions: what is affected, when it starts and ends, what the user will see, and whether they need to do anything. If it’s missing any of these, people will fill the gap with guesses, and the guesses are usually worse than the truth.
A Practical Timeline for Announcing Scheduled Maintenance
Picture a familiar scenario. A small SaaS team plans a PostgreSQL major version upgrade from 15 to 17. They expect 40 minutes of read-only mode and up to 10 minutes of full downtime. Their customers include European accounting firms that run batch exports late at night, so “nobody uses it at 2 AM” is not true for this audience.
An experienced SRE builds the communication schedule backwards from the window:
7-14 days before: first announcement by email and on the status page, with the exact window in UTC and the main customer time zones.
48 hours before: a reminder, ideally only sent to users of the affected feature.
1-2 hours before: an in-app banner and a status page update.
At start: the status page changes to “In progress”.
At completion: a short “completed” update, including anything that changed.
For routine work under 5 minutes with zero user-facing impact, such as a rolling deploy behind a load balancer, this whole sequence is overkill. A status page entry is enough. Save the full sequence for work that users will actually notice, or you train them to ignore your notices.
Writing the Notice Itself
Lead with impact, not with the reason. Users care that file uploads will pause for 15 minutes. They don’t care that you’re “migrating object storage to a new availability zone.” Put the technical background in a second paragraph for anyone curious.
Always give times in UTC and in at least one local zone, written out in full: “Sunday 15 November, 02:00-02:45 UTC (03:00-03:45 CET)”. Avoid “tonight” or “this weekend” – a global user base doesn’t share your weekend. Attaching an .ics calendar file is a small thing that ops-heavy customers really appreciate.
Give a maximum duration, not an optimistic one. If the runbook says 25 minutes, announce 45. Finishing early looks competent. Overrunning by ten minutes looks like an incident, even when nothing is wrong.
Leave out words like “critical”, “urgent” and “security” unless they’re true. A routine kernel patch announced as a “critical security update” will bring in a wave of questions from customers’ compliance teams asking whether they were breached.
Choosing Channels and Handling Edge Cases
A hosted status page such as Atlassian Statuspage, Instatus, or a self-hosted Cachet instance should be the single source of truth. Email and in-app banners point to it. If you don’t have one yet, the reasoning behind creating a status page applies directly here, since maintenance notices are the most common thing a status page publishes.
Some environments need more than this. Regulated customers in finance or healthcare often have contracts requiring written notice 5-30 days ahead, and a status page post may not count as notice. Check the SLA language. Planned maintenance is usually excluded from uptime calculations only if it was announced within the agreed notice period. For B2B products with fewer than 50 customers, a personal email from the account owner often works better than any automated system.
Non-English markets need translated notices, not a machine-translated footnote. A Japanese or German customer who skims past an English-only email has effectively not been told.
Common Mistakes That Cause Unnecessary Alarm
Pausing monitoring and forgetting to resume it. This is a classic. A team disables HTTP checks before the window, the upgrade finishes, everyone goes to bed, and the checks stay paused for three days. Meanwhile a memory leak introduced by the upgrade takes the site down on Tuesday and nobody gets a downtime alert. Use a maintenance window that ends automatically, not a manual pause.
Serving the wrong status code. A maintenance page that returns HTTP 200 tells search engines your homepage now says “We’ll be back soon.” A real outage page returning 500 looks like a broken server. The correct response is 503 Service Unavailable with a Retry-After header, which Google explicitly recommends for temporary downtime. WordPress’s built-in maintenance mode already returns 503; many custom maintenance pages behind Nginx don’t, so check with curl -I before the window.
Announcing the same window three times with different times. Rescheduling happens. Sending a correction without clearly saying the earlier time is cancelled leaves users unsure which one is real. Update the original status page entry instead of creating a new one.
The Myth That Monitoring Should Go Quiet During Maintenance
The common belief is that monitoring is noise during a maintenance window, so you turn it off. The opposite is true. The window is exactly when you most need to know the moment the site comes back, and whether it comes back correctly.
The smarter approach is to suppress alert notifications while keeping the uptime checks running and recording data. That gives you a precise timeline: the site went down at 02:03, returned at 02:31, and response time stabilised by 02:38. If it doesn’t return by the announced end time, notifications resume and someone gets woken up. The data also helps you tell planned outages apart from real ones in monthly reports, which is the core of the difference between scheduled and unscheduled downtime.
Keep SSL certificate and keyword checks running too. A load balancer swap that serves an expired default certificate, or a deploy that returns 200 with an empty page, won’t show up as “down” on a plain status code check.
FAQ
How far in advance should scheduled maintenance be announced?
For user-facing downtime, 7-14 days is a good default for the first notice, with a reminder 48 hours before. Contracts in regulated industries may require longer notice, so check your SLA.
Should scheduled maintenance count against uptime?
Usually not, if it was announced within the agreed notice period and stayed inside the announced window. Any overrun beyond the window should normally be counted as unplanned downtime.
What HTTP status code should a maintenance page return?
Use 503 Service Unavailable with a Retry-After header. This tells browsers, crawlers and monitoring tools that the outage is temporary and intentional.
Final Practical Tip
Treat the announcement as part of the runbook, not something added afterwards. Write the notice when you plan the work, set an automatic maintenance window in your monitoring, check the 503 response, and pad the duration. Then post the “completed” update promptly. A short, calm closing message is what users remember, and it’s how the next announcement earns their trust. For the harder case where things go wrong mid-window, the principles of communicating downtime to customers take over from here.