A maintenance notice does two jobs. It tells your customers when their service will be affected, and it gives them a chance to plan around it. Most small teams get the second part right by accident and miss the first, so the notice ends up vague, late or buried. This guide covers when to give notice, a short example you can adapt, what to send on the day, and how to word an unplanned outage when there was no time to warn anyone.
When to give notice and how far ahead
Give notice as early as you can, but be realistic about what you already know. For planned work that will take the service down or slow it noticeably, three to five working days is a sensible minimum for most small web apps. If your customers run their own businesses on your product, or the work touches billing, logins or data, give a full week.
Short, routine work such as a restart or a minor patch can be announced one or two days ahead, provided the impact is small and you say so. Do not promise a window you have not planned. If the work might overrun, say what happens if it does, for example that you will post an update every 30 minutes until service is back.
Write the notice before you start the work, not after. The notice forces you to name the window, the affected parts and the rollback plan, and those are the things your team will need on the night anyway.
A short notice with the date written in full, time window and what will be affected
Use full dates in every notice. Write the day, the date and the month, for example Friday 14 March 2025, rather than 14/3 or 3/14. Customers in different countries read numbers differently, and a short date invites mistakes. Give the time window with a time zone, and state the affected parts in plain words. Here is an example you can adapt:
Scheduled maintenance: Friday 14 March 2025, 22:00 to 23:30 GMT
We will be upgrading our database servers during this window. The web dashboard and the API will be unavailable for up to 60 minutes. Monitors will keep checking your sites, but alerts may arrive up to 15 minutes late. Your data will not be changed.
If the work runs past 23:30 GMT, we will post an update here every 30 minutes until the service is back.
This notice does four things. It names the date and window, so nobody has to convert time zones in their head. It says what stops working and what keeps working. It states the risk of delay in concrete terms. And it tells people where to look for updates, which should be the same place they will see the completion note.
Publish the notice on your status page so that it sits next to your incident history. Customers who check the page before they start work will see it there, and you do not have to rely on anyone reading a single email.
Reminder on the day and a completion note
Send a short reminder on the day of the work, a few hours before the window opens. Repeat the date and window, and say whether anything has changed. People forget, and a reminder is cheap. Keep it to three or four lines.
When the work is finished, post a completion note. Many teams skip this, and customers are left wondering whether the window passed quietly or whether something broke. A completion note should say that the work is done, confirm the service is running normally, and mention anything the customer needs to do, such as clearing a cache or signing in again. If something was not finished, say so and give the next step.
Here is a completion note in the same style:
Maintenance complete: the database upgrade finished at 22:48 GMT on Friday 14 March 2025. The dashboard and API are back and checks are running as normal. No action is needed from you.
The completion note also closes the loop in your own records. If the notice and the completion note sit together on your status page, anyone who looks back later can see what happened and when.
How to tell customers about unplanned downtime in two sentences
Some outages arrive without warning. When that happens, you do not need a long statement at the start. Two sentences are enough: say what is affected, and say what you are doing about it.
For example: The sign-in page and the API are returning errors from 09:14 GMT on Tuesday 4 February 2025. We are checking the database connection and will post the next update by 09:45 GMT.
Then keep the updates coming at a fixed interval, even if the update is only that the investigation is continuing. A promised time for the next update is more useful than a long explanation. Once the service is back, add a short note with the time it recovered and a one-line cause if you know it. Save the longer write-up for after the incident, when you have the facts.
Mistakes to avoid
The most common mistakes are easy to fix once you can see them.
The first is giving no time window. A notice that says maintenance will happen this week is not useful. Give a start time and an end time, and say what you will do if the work runs over.
The second is writing in internal jargon. Customers do not know what a failover is or which cluster you mean. Describe the effect on them, such as the dashboard being unavailable, and leave the technical detail for your team.
The third is using numeric dates. Write 14 March 2025, not 14/03/25, and check that the day of the week matches the date before you publish.
The fourth is promising more than you can deliver. Do not say the work will take no time or that nothing will be affected unless you have tested that. Say what you expect and what you will monitor.
The fifth is forgetting the completion note. A window that ends in silence makes customers less confident in your next notice.
The last mistake is posting notices in several places that disagree. Keep one source of truth, usually your status page, and link to it from anywhere else you talk to customers.
AperioFlow can help with the monitoring side of this. You can set up monitors for the parts of your service your customers rely on, alert the people in your organisation when a check fails, and publish maintenance and incident updates on your status page. The free plan includes 10 monitors, so you can try it on your own site before you decide on anything else. Start free at https://app.aperioflow.co.uk/#/signup