
Planned maintenance is an opportunity to demonstrate professionalism. Done well — clear notice, accurate timing, prompt "all clear" — it builds rather than erodes user trust. Done poorly, it feels like unplanned downtime with a disclaimer attached.
This guide covers when and how to communicate planned maintenance, with templates you can adapt for status pages, emails, and in-app banners.
Give enough notice. For routine maintenance affecting a small number of users briefly, 24–48 hours is fine. For extended maintenance or anything affecting business-critical workflows, give at least a week's notice. For major migrations, two or more weeks.
Be specific about time. "Saturday morning" is vague. "Saturday 23 March, 02:00–04:00 UTC" is specific. Always include the timezone (UTC is safest since your users may be global) and local time equivalents if your user base is concentrated in a particular region.
Be clear about what will be affected. "Brief maintenance" tells users nothing. "Read-only mode for the dashboard — no new monitors can be added, but existing monitoring will continue" tells them exactly what to plan around.
Communicate when you're done. Post a completion notice promptly when maintenance finishes. Users checking your status page want to know it's over — don't leave an "in progress" maintenance notice up for hours after you've finished.
Under-promise and over-deliver on time. If you think maintenance will take 1 hour, schedule 2. Finishing early is a pleasant surprise; running over is a problem.
Post this 24–72 hours before maintenance.
Scheduled Maintenance — [Date]
We will be performing scheduled maintenance on [specific date] between [start time] and [end time] UTC ([local time equivalent]).
What will be affected: [List affected services — be specific. E.g., "The monitoring dashboard will be in read-only mode. Active monitors will continue running and alerts will still fire. No new monitors can be created during this window."]
What will not be affected: [List services that continue normally — reassure users about the things they care most about.]
We expect [full service / the affected features] to be restored by [end time]. If we finish earlier, we will post an update immediately.
We apologise for any inconvenience.
Post this at the start of the maintenance window.
Maintenance In Progress — Started [time] UTC
Scheduled maintenance has begun. [Brief description of what's happening.]
Estimated completion: [end time] UTC
We will post an update when maintenance is complete.
Post this as soon as maintenance finishes.
Maintenance Complete — [time] UTC
Scheduled maintenance has been completed successfully. All services are operating normally.
Total duration: [X hours Y minutes] ([shorter / longer] than estimated).
Thank you for your patience.
If maintenance ran long, acknowledge it briefly:
Maintenance Complete — [time] UTC
Scheduled maintenance has been completed. All services are operating normally.
The maintenance ran approximately [X] minutes longer than scheduled due to [brief reason — e.g., "a larger-than-anticipated database migration"]. We apologise for the extended window.
For significant maintenance windows, email affected customers directly. Send 3–7 days in advance.
Subject: Scheduled Maintenance – [Your Product] – [Date]
Hi [Name],
We're writing to let you know that [Product Name] will be undergoing scheduled maintenance on:
[Day, Date] from [start time] to [end time] UTC ([Equivalent in relevant timezone, e.g., "9pm–11pm Eastern"])
What this means for you: [Specific impact — what they can and cannot do during the window. Keep this concrete.]
What will continue working: [Reassure them about services that keep running.]
We've scheduled this work during [off-peak hours / the weekend] to minimise disruption. Our team will be available throughout and we expect to complete well within the scheduled window.
You can follow the maintenance progress at [your status page URL].
If you have any questions or this maintenance window causes significant difficulty for your team, please reply to this email and we'll do our best to help.
Thank you, [Your name] [Product Name] Team
Display this inside your application starting 24–48 hours before the window.
⚠️ Scheduled Maintenance: [Product Name] will undergo scheduled maintenance on [Day, Date] from [start time]–[end time] UTC. [Brief impact statement.] [Link to status page for details.]
Keep in-app banners short. Users dismissing them still need to have seen the key facts: date, time, and what's affected. Link to the status page for full details.
If maintenance caused significant disruption or ran longer than expected, a post-maintenance email closes the loop.
Subject: Maintenance Complete – [Product Name] is fully operational
Hi [Name],
Our scheduled maintenance completed at [time] UTC today. All services are fully operational.
[If it ran long:] The maintenance took approximately [X] minutes longer than our planned window due to [brief explanation]. We apologise for the extended impact.
[Summary of what was done — optional, but appreciated for significant upgrades:] During this maintenance we [brief description of what changed or improved — e.g., "upgraded our database infrastructure to improve query performance and reliability"].
If you notice anything behaving unexpectedly, please contact us at [support email].
Thank you for your patience.
[Your name] [Product Name] Team
| Maintenance type | Advance notice | Email customers? | Post completion? |
|---|---|---|---|
| Routine, brief, off-hours | 24 hours | No | Yes |
| Extended (2+ hours) | 48–72 hours | Yes | Yes |
| Major migration or upgrade | 1–2 weeks | Yes | Yes |
| Emergency maintenance | As much as possible | Yes (brief) | Yes |
Domain Monitor supports maintenance windows so scheduled downtime doesn't trigger false positive alerts to your team. Create a free account and configure maintenance windows to silence monitoring during planned work.
See maintenance windows for pro users for how to configure these in Domain Monitor, and how to create a public status page for setting up the status page where these notices live. If you're deciding whether your maintenance notices should appear on a customer-facing page, an internal engineering page, or both, see internal vs public status pages: when you need both.
When your site goes down, your status page becomes the most important page you have. Here's why it matters, what happens when you don't have one, and what a good status page does during a real outage.
Read moreYour domain is resolving, but pointing to the wrong server — showing old content, a previous host's page, or someone else's site entirely. Here's what causes this and how to diagnose it.
Read moreUptime monitoring isn't foolproof. Single-location monitors, wrong health check endpoints, long check intervals, and false positives can all cause real downtime to go undetected. Here's what to watch out for.
Read moreLooking to monitor your website and domains? Join our platform and start today.