A good maintenance announcement tells customers when work will happen, what may be affected, and what they should expect before, during, and after the change. The goal is not to announce that “maintenance exists.” The goal is to let customers plan around risk.
If you want the product workflow, see Incident management and Create a public status page. This guide gives you reusable maintenance copy.
What every maintenance notice should include
Every announcement should answer:
- when the work starts and ends
- which services are affected
- whether downtime or degraded performance is expected
- whether customer action is required
- when the final completion update will be posted
Maintenance announcement template
We will perform scheduled maintenance on [date] from [start time] to [end time] [timezone]. During this window, [affected service or component] may experience [expected impact]. We will post updates here if the maintenance window changes or if customer impact differs from plan.
Example: expected brief downtime
We will perform scheduled maintenance on March 14 from 01:00 to 01:30 UTC. During this window, API write requests may be briefly unavailable for up to 5 minutes. Read requests and the status page will remain available.
Example: degraded performance only
We will perform scheduled database maintenance on March 18 from 02:00 to 03:00 UTC. During this window, some customers may experience elevated latency in dashboard reporting. Core application access is expected to remain available.
Completion update template
Scheduled maintenance has been completed. All affected services are operating normally. If you continue to see issues, please contact support and reference this maintenance window.
Delay update template
Scheduled maintenance is taking longer than expected. We are extending the maintenance window until [new time]. Current impact remains [impact]. We will share another update by [time].
Practical writing rules
- be explicit about expected impact
- avoid vague phrases like “minimal disruption” unless you define what that means
- use customer-facing component names
- publish early enough for customers to plan around the window
A simple maintenance checklist
| Item | Why it matters |
|---|---|
| Start and end time | Customers need planning context |
| Affected services | Customers need scope |
| Expected impact | Customers need to assess risk |
| Completion update | Customers need closure |
For general incident updates, use Incident communication templates.
FAQ
How early should a maintenance announcement be published?
That depends on customer impact, but teams should publish early enough that affected users can plan around the maintenance window.
Should maintenance announcements mention exact risk?
Yes. If you expect downtime, delays, or degraded performance, say so directly. That is more useful than generic reassurance.
Do maintenance windows need completion updates?
Yes. Customers need confirmation that the work is finished and that the service is back to normal.