Scheduled maintenance notice templates
Planned downtime is easier to accept when people hear about it early and know exactly what will be unavailable, for how long, and what to do.
Templates
Replace the parts in [brackets].
Announcement
A week or more ahead for anything customers will notice.
Scheduled maintenance: [what], [date], [start] to [end] UTC. During this window, [what will be unavailable or slower; what keeps working]. [Anything customers should do before, e.g. finish exports.] We'll post here when it starts and when it is done.
Reminder
The day before.
Reminder: [what] starts tomorrow, [date], at [start] UTC and should take [duration]. [What will be unavailable.]
Started
When the work begins.
Maintenance has started. [What is unavailable] until about [end] UTC. We'll update here when it is complete.
Running late
As soon as you know the window will not be enough.
The maintenance is taking longer than planned because [short reason]. We now expect to finish by [new end] UTC. [What is still unavailable.]
Completed
When everything is back.
The maintenance is complete and [service] is fully available again. [Anything customers should do now, e.g. sign in again.] Thanks for your patience.
Writing tips
- Give the window with its time zone, and pad it: finishing early is good news, overrunning is an incident.
- Say what keeps working as well as what does not; people often only need to know that their part is fine.
- Pick the hours with the least traffic for your customers, not for your team.
- If the work ends early, say so and close the window rather than leaving it open.
In OpenUptime
- Schedule a maintenance window for some or all monitors, once or on a repeating schedule.
- During a window, checks still run and are recorded, but failures open no incidents and send no alerts.
- The window shows on the status page and in its RSS feed.
- Subscribers get an email reminder before it starts, 24 hours by default; each status page can change the lead time or turn it off.
Publish these on a status page
Status pages, incident updates and subscriber emails are included on the Free plan. No card needed.
Questions
How far in advance should I announce maintenance?
A week is a common default for maintenance customers will notice, longer for anything that needs them to act. Send a reminder the day before.
Will my monitors alert during maintenance?
Not in OpenUptime. Monitors covered by a maintenance window keep checking and recording results, but failures do not open incidents or send alerts until the window ends.
What if maintenance takes longer than planned?
Post an update as soon as you know, with a new end time, and extend the window so checks stay quiet. If customers are affected beyond what you announced, treat it as an incident.
计划维护通知模板
如果用户提前得知，并清楚知道哪些功能不可用、持续多久、需要做什么，计划停机就更容易被接受。
模板
替换 [方括号] 中的内容。
提前公告
对用户有感知的维护，提前一周或更早发布。
计划维护：[内容]，[日期] 北京时间 [开始] 至 [结束]。 维护期间，[哪些功能不可用或变慢；哪些不受影响]。[需要用户提前做的事，例如提前完成导出。] 维护开始和结束时，我们都会在这里更新。
开始前提醒
维护前一天。
提醒：[内容] 将于明天 [日期] 北京时间 [开始] 开始，预计持续 [时长]。[不可用的功能。]
维护开始
维护开始时。
维护已经开始。在北京时间 [结束] 左右之前，[不可用的功能]。完成后我们会在这里更新。
延长维护
一旦发现时间窗口不够用就发布。
由于 [简短原因]，本次维护比计划用时更长。我们预计在北京时间 [新的结束时间] 前完成。[仍不可用的功能。]
维护完成
一切恢复正常时。
维护已完成，[服务] 已全面恢复。[用户现在需要做的事，例如重新登录。] 感谢你的耐心等待。
写作建议
- 写明时间窗口和时区，并留出余量：提前完成是好消息，超时就成了故障。
- 既要写哪些功能不可用，也要写哪些不受影响；很多人只想确认自己用的部分没问题。
- 选择用户访问量最低的时段，而不是团队最方便的时段。
- 如果提前完成，及时说明并结束维护窗口，不要让它一直挂着。
在 OpenUptime 中
- 可以为部分或全部监控安排维护窗口，单次或按周期重复。
- 维护期间检查照常运行并记录结果，但失败不会创建故障，也不会发送告警。
- 维护窗口会显示在状态页和它的 RSS 订阅源中。
- 订阅者会在维护开始前收到邮件提醒，默认提前 24 小时；每个状态页都可以修改提前时间或关闭提醒。
常见问题
计划维护要提前多久通知？
对用户有感知的维护，常见做法是提前一周；需要用户配合的，要更早。维护前一天再发一次提醒。
维护期间监控会告警吗？
在 OpenUptime 中不会。维护窗口覆盖的监控会继续检查并记录结果，但在窗口结束之前，失败不会创建故障，也不会发送告警。
维护超时怎么办？
一旦发现就发布更新，写明新的结束时间，并延长维护窗口，避免检查告警。如果对用户的影响超出了公告的范围，就按故障来处理。