Maintenance windows on a status page should do one job well: help customers understand planned work before it becomes confusion. A useful maintenance entry explains timing, expected impact, affected services, and what customers should watch for while the work is happening.
If you want the feature side, see Maintenance Windows and Create a public status page. This guide focuses on the operating model.
Industry surveys find that customers who receive advance notification of maintenance windows are significantly less likely to file support tickets when the work causes visible impact — the communication does more to protect trust than the brevity of the outage window itself. Based on operational experience at StatusPage.me, maintenance windows that include a public completion update see better customer satisfaction scores than windows that go silent after the work starts, even when the work completes on time.
What a maintenance window should show
At minimum, the status page entry should include:
- start time
- expected end time
- affected components
- expected impact
- follow-up update when work completes
If any of those are missing, customers have to guess too much.
Planned work needs separate visibility
Maintenance should not be buried in the same feed as general status copy without clear labeling.
Customers need to tell the difference between:
- planned work
- active unplanned incident
- post-maintenance monitoring
That distinction keeps expectations aligned.
If customers can subscribe to updates, planned work is much easier to communicate without relying on support tickets or manual reminders. See Status page subscription options.
Good maintenance communication is specific
Weak maintenance notice:
We will perform scheduled maintenance tonight.
Better maintenance notice:
We will perform scheduled database maintenance from 01:00 to 01:30 UTC. API write requests may be briefly unavailable for up to 5 minutes during this window.
For reusable wording, see Maintenance announcement template.
What happens during the window
During the maintenance window, the status page should be ready to handle three cases:
| Case | What to publish |
|---|---|
| Work proceeds as planned | Keep the original notice visible |
| Impact is different than expected | Publish an update immediately |
| Window runs long | Extend the window publicly with a new time |
After the work finishes
Do not leave the maintenance item ambiguous after the work ends.
Customers need closure:
- maintenance completed
- services operating normally
- note if extra monitoring is underway
Practical rules
- publish early enough for customers to plan around it
- describe customer impact directly
- treat overrun updates like real communications, not internal notes
- keep maintenance history visible if it affects trust or auditability
How StatusPage.me handles this
StatusPage.me gives maintenance windows their own section on your status page, visually distinct from the active incident feed. When you create a maintenance window, you set the timing, select affected components, and describe expected impact — all in one form. Subscribers receive an advance notification automatically; you do not need to send it manually. During the window, you can post progress updates the same way you post incident updates. When the work finishes, marking the window as complete sends a closure notification to subscribers and moves the entry to maintenance history. See the full setup at Maintenance Windows.
FAQ
Should maintenance windows appear on the public status page?
Yes, if customers may notice the work or need to plan around it. Planned impact is still customer impact.
How detailed should a maintenance window be?
Detailed enough to explain timing, scope, and expected effect, but not overloaded with internal engineering detail.
What if maintenance finishes early?
Publish a completion update anyway. Customers need confirmation that the work is done and the service is normal again.
