Scheduled Maintenance Done Right Builds Trust
A scheduled maintenance page is your opportunity to demonstrate operational professionalism. Unplanned outages damage trust. Planned maintenance, communicated properly, does the opposite. It shows users that your team actively maintains and improves the service.
The difference between "why is the app down?" and "I saw the maintenance notice, thanks for the heads up" is entirely about communication.
How Much Advance Notice to Give
The right amount of notice depends on your user base and the severity of the maintenance.
24 hours minimum for routine maintenance with brief impact (under 30 minutes of downtime). This covers database migrations, security patches, and infrastructure updates.
48-72 hours for maintenance that will cause extended downtime (1+ hours) or significant feature changes. This gives users time to plan around the disruption.
1-2 weeks for major migrations, breaking API changes, or maintenance during peak business hours. Enterprise customers especially need this lead time to coordinate with their own teams.
Exception: Emergency security patches may require shorter notice. If you're patching a critical vulnerability, 4-6 hours of notice is acceptable. Explain why in your notification.
Choosing Your Maintenance Window
Pick a time that minimizes user impact. This requires knowing when your users are active.
Check your analytics:
- When is traffic lowest? For a US-focused B2B SaaS, that's typically 2-5 AM Eastern on weekday nights.
- For global services, there is no perfect window. Choose the region with the least traffic and communicate clearly to other regions.
Best practices:
- Avoid Mondays (start of business week) and Fridays (people doing last-minute work)
- Avoid the last day of the month (billing cycles, reporting deadlines)
- Stick to a consistent window so users learn your pattern (e.g., "maintenance occurs on the first Sunday of each month from 2-4 AM EST")
- Never schedule maintenance during known peak events (product launches, end-of-quarter, holiday sales)
What to Include in a Maintenance Notification
Every maintenance notification should answer five questions:
- When? Exact date and time with timezone. Include a countdown or "time until" for clarity.
- How long? Expected duration. Always pad by 25-50% to avoid running over.
- What's affected? Which services or features will be unavailable or degraded.
- What's NOT affected? Explicitly list what will continue working. This prevents unnecessary panic.
- Why? A brief explanation of what you're improving. Users are more patient when they understand the purpose.
Template: Standard Maintenance Notification
Subject: Scheduled Maintenance - [Date] at [Time] [Timezone]
We will be performing scheduled maintenance on [date] from
[start time] to [end time] [timezone].
During this window, [specific service/feature] will be
unavailable. [Other services] will not be affected.
We are performing this maintenance to [brief reason: upgrade
database infrastructure, apply security patches, improve
system performance].
No action is required on your part. We will update our
status page when maintenance begins and when it's complete.
If you have questions, contact [email protected].
Template: Major Migration Notification
Subject: Important: Scheduled Maintenance on [Date] - Extended Window
On [date], we will perform a major infrastructure upgrade
from [start time] to [end time] [timezone]. This maintenance
window is longer than usual.
What's changing:
- [Specific improvement 1]
- [Specific improvement 2]
What to expect:
- [Service A] will be completely unavailable during this window
- [Service B] will operate in read-only mode
- [Service C] will not be affected
What you should do:
- Save your work before [start time]
- [Any specific action needed from users]
We will send a reminder 1 hour before maintenance begins
and update our status page throughout the process.
Using Your Status Page for Maintenance
Your status page should reflect scheduled maintenance prominently.
Before Maintenance
Create a scheduled maintenance event on your status page 24-72 hours in advance. This displays a banner showing the upcoming window, duration, and affected components.
Most status page tools, including alert24.net, Instatus, and Better Stack, support scheduled maintenance events that automatically notify subscribers when created.
During Maintenance
Update the status page component to "Under Maintenance" when the window begins. Post updates every 30 minutes during extended maintenance:
- "Maintenance has started. Database migration is in progress."
- "Database migration complete. Running validation checks."
- "Validation complete. Bringing services back online."
After Maintenance
Mark the maintenance as complete and update all components to "Operational." Send a notification confirming that the maintenance finished successfully and all services are restored.
If the maintenance ran longer than expected, briefly explain why in the resolution update.
Subscriber Notification Channels
Let users choose how they want to be notified about maintenance:
Email is the standard. Send the initial notice, a reminder 1 hour before, and a completion confirmation.
Slack/Webhook for teams that integrate your status into their own dashboards or channels. Developers building on your API especially value this.
In-app banners for logged-in users. Show a dismissible notice with the maintenance schedule. This catches users who don't check email frequently.
SMS for critical services where users need immediate awareness. Use sparingly since SMS fatigue is real.
Handling Overruns
Your maintenance window will occasionally run longer than planned. This is expected. How you handle it determines whether users are annoyed or understanding.
If you suspect an overrun before the window ends: Post an update 15 minutes before the expected end time: "Maintenance is taking longer than expected. We now estimate completion by [new time]. [Brief reason for delay]."
If maintenance has run over without warning: Post immediately: "Maintenance is running past our planned window. [Brief explanation]. We expect to complete within [timeframe]."
Prevention: Always pad your maintenance window by 25-50%. If you think a migration takes 2 hours, schedule 3 hours. Finishing early is a pleasant surprise. Running over is a communication failure.
Maintenance Policies for APIs
API consumers need extra care during maintenance. Their systems depend on yours programmatically.
Provide a maintenance schedule API endpoint that returns upcoming maintenance windows in JSON format. This lets API consumers automate their own notifications or failover procedures.
Use appropriate HTTP status codes during maintenance. Return 503 Service Unavailable with a Retry-After header indicating when the service will return. This tells well-built clients to back off and retry automatically.
Version your maintenance notifications so API consumers can filter by the services they use. A developer using only your authentication API doesn't need notifications about billing system maintenance.
Building a Maintenance Calendar
For teams with multiple services and regular maintenance needs, publish a maintenance calendar.
- Use a shared Google Calendar or webcal feed
- Include all planned maintenance windows for the quarter
- Update it as schedules change
- Link to it from your status page and documentation
This gives enterprise customers and API partners the predictability they need to plan their own operations around your maintenance schedule.