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.
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
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.