A useful maintenance notice tells affected customers what will change, when it will happen and what they need to do. Prepare the notice from the approved technical change so its scope and timing are accurate.
01 Prepare the communication plan
- Identify the affected services and customers from actual provider and billing records. Include dependent services, such as email or DNS, only when they are part of the change.
- Confirm the maintenance window with an explicit timezone, expected customer impact and the next update time. Separate expected interruption from uncertainty that is still being investigated.
- State any action the customer needs to take and the deadline. If no action is needed, say so plainly.
- Choose the approved channel, such as a service notice, status page or targeted ticket. Check contact permissions and recipient lists before sending.
- Prepare progress, extension and completion messages in advance. Assign one person to approve updates and one to maintain the technical evidence.
- After the work, verify the affected functions before issuing a completion notice. Report any remaining limitation with a clear next step.
02 Use a clear notice structure
Example: Scheduled maintenance will affect [service] on [date] from [start] to [end, timezone]. During this period, [specific function] may be unavailable for approximately [verified estimate]. Please [required customer action] before [deadline]. We will post the next update at [time] through [status or support link].
Replace every placeholder with verified information. Avoid promising zero downtime when the change can interrupt access. If the window extends, explain the present condition and the next update time even when a final recovery estimate is not yet available.
Common questions
Should I notify every customer about one server?
Target customers whose services depend on that server, while using a broader public status notice when appropriate. Accurate targeting reduces confusion and helps affected customers recognise the relevance.
What if the change finishes early?
Publish completion only after the planned verification succeeds. Include the actual result and any customer checks needed, such as confirming an application integration after a connection change.