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.
Industry surveys find that customers rate advance notice and clear impact descriptions as the two most important factors in how they perceive planned maintenance — more important than the duration of the work itself. Based on operational experience at StatusPage.me, maintenance windows that include explicit expected impact wording generate far fewer “is this affecting me?” support questions than notices that use vague phrases like “minimal disruption.” Specificity is the most actionable thing you can add to a maintenance announcement.
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.
We will perform scheduled maintenance on [date] from [start time] to [end time] [timezone]. During this window, some customers may experience degraded performance in [affected service], but core access is expected to remain available.
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].
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.
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.
How StatusPage.me handles this
StatusPage.me has a dedicated maintenance workflow that keeps planned work separate from the active incident feed on your status page. When you schedule a maintenance window, you set the start time, expected end time, and affected components — subscribers receive a notification automatically so customers know before the work begins. During the window you can post in-progress updates using the same interface as incident updates. When the work finishes, you mark the window as completed and subscribers receive the closure notification. The full maintenance workflow is available from Incidents and your status page dashboard at Create a public status page.
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.
