A database upgrade is expected to take 20 minutes, so the team schedules a 30-minute maintenance window at midnight.
The change itself finishes in 18 minutes.
Then validation finds a problem.
Rollback takes another 25 minutes, the application needs time to restart, and several background jobs have to catch up before customers can safely use the service again.
The maintenance task fit inside the window.
The maintenance operation did not.
That distinction is important because a maintenance window is not simply the estimated time required to run an update.
A maintenance window is a predefined period during which planned changes can be made to an application or its infrastructure with controlled risk and, where necessary, an accepted possibility of reduced availability or downtime.
The window gives engineering room to perform the change, verify the result and recover if something goes wrong while users and business teams know when disruption may occur.
Cloud providers use the same idea. Amazon RDS lets teams define a preferred weekly maintenance window during which system maintenance may be initiated, and AWS explicitly recommends placing that window during periods of lowest usage.
For Levelworks, maintenance windows primarily support Seamlessly Updatable App Health. They also reinforce Resilient and Observable health because a safe window needs both a recovery plan and enough monitoring to confirm that the application is healthy before normal operation resumes.
A maintenance window is appropriate when a planned change may temporarily affect availability, performance or operational risk.
Typical examples include:
Not every deployment needs one.
If an application can deploy a routine release with no interruption and safely roll it back while serving users normally, creating a customer-facing maintenance period may be unnecessary.
The decision should depend on the impact of the change, not simply on whether engineering calls it maintenance.
Managed platforms illustrate this distinction well. Azure notes that much of its infrastructure maintenance can occur with little or no customer impact, while maintenance that requires a reboot receives a planned window so customers can prepare or initiate the change themselves.
The traditional answer is to schedule maintenance overnight.
That only works if overnight is actually quiet for your application.
A service used internationally may have no universal off-hours. An ecommerce platform may see relatively little traffic at 2 a.m. during most of the year but heavy usage during a holiday sale. A payroll application may have unusually important traffic around specific processing dates.
Use production evidence such as:
AWS specifically recommends adjusting RDS maintenance windows to periods of lowest usage, while Azure SQL offers maintenance-window options designed to move planned changes outside peak business hours.
The best maintenance period is therefore not necessarily the time with the fewest users. It is the time when a temporary degradation would create the least business impact.
A quiet customer period can still be a poor maintenance window if the application is busy internally.
Check whether the proposed window overlaps with:
Amazon RDS, for example, does not allow its preferred backup window and maintenance window to overlap.
Even where a platform permits overlap, stacking several heavy operational activities together can make troubleshooting harder. If performance falls during the maintenance period, you want to know whether the cause is the upgrade itself rather than three unrelated jobs running simultaneously.
A maintenance plan that says:
Upgrade takes approximately 45 minutes, therefore schedule 45 minutes.
has almost no tolerance for uncertainty.
A better estimate includes:
Change time + validation time + rollback/recovery time + operational buffer
Suppose:
Activity
Planned time
Pre-change checks
10 min
Upgrade
35 min
Validation
15 min
Rollback allowance
30 min
Buffer
20 min
Total window
110 min
That does not mean customers will experience 110 minutes of downtime.
It means engineering has reserved enough controlled time to deal with more than the ideal path.
Azure Update Manager reflects the same principle operationally: it will skip some updates when insufficient time remains in the configured maintenance window rather than begin work that cannot reasonably finish within it.
Every maintenance window should have a point at which the team stops trying to complete the change and switches to recovery.
For example:
If the new database version is not healthy by 02:10, begin rollback so service can be restored before the 03:00 maintenance-window end.
Without that decision point, teams can spend most of the window troubleshooting, then discover too late that there is no longer enough time to restore the previous state safely.
A window should protect recovery time, not merely deployment time.
[Internal Link: “Backup and Disaster Recovery: What Every App Maintenance Plan Needs”]
A production maintenance window should not be the first time the sequence is performed.
Where practical, rehearse the change in a staging or representative environment.
Google Cloud SQL offers maintenance timing controls that can be used to receive maintenance on test environments before production. Its documentation specifically gives the example of applying maintenance earlier in staging so teams have time to validate the update before production receives it.
For your own maintenance activities, a rehearsal can reveal:
This makes the production window a controlled execution of something understood rather than a timed experiment.
Users need more than:
Maintenance: Saturday, 1–3 a.m.
A useful notification explains:
Atlassian Statuspage's scheduled-maintenance model includes start time, duration, affected components and notifications before, during and after the maintenance event. It also includes a verifying state between the work itself and declaring the maintenance completed.
That intermediate state is useful.
Finishing the technical change should not automatically mean telling customers everything is operational.
First confirm it.
After maintenance, verify the workflows that matter most.
Depending on the change, that might include:
Do not rely entirely on the fact that services restarted successfully.
A database may be online while an application cannot connect correctly. A deployment can be healthy at the infrastructure level while a business-critical workflow is returning errors.
Only close the window once the team has evidence that normal service has actually returned.
[Internal Link: “Application Incident Response: What Should Happen When Your App Goes Down?”]
No.
Modern deployment and infrastructure techniques can allow many changes to occur without taking an entire application offline.
A maintenance window can still be useful even when downtime is not expected because it defines a controlled period in which riskier operational changes are allowed and support staff are prepared to respond.
Azure SQL, for example, allows teams to select windows for impactful planned maintenance even though databases generally remain available and may experience only short reconfigurations.
The window is therefore about risk control, not necessarily planned unavailability.
[Internal Link: “Zero-Downtime Deployment: How to Update an App Without Taking It Offline”]
Before scheduling the change, confirm:
Decision
Question to answer
Timing
When is business impact lowest?
Duration
Is there time for change, validation and rollback?
Conflicts
Are backups, jobs or other changes running simultaneously?
Ownership
Who executes the change and who decides whether to roll back?
Recovery
What is the rollback point and how long does recovery take?
Communication
Who needs advance notice and status updates?
Validation
Which workflows prove that service is healthy again?
The most important mistake to avoid is treating a maintenance window as a calendar reservation rather than an operational safety boundary.
For Levelworks, Seamlessly Updatable App Health means making planned change predictable enough that maintenance does not become an improvised outage. A well-designed window creates room not only to make the change, but also to verify it and recover safely if reality differs from the plan.
The scheduling question is therefore not simply:
“When can we perform the maintenance?”
It is:
“When can we make this change with the lowest business impact while still leaving enough time and people available to recover safely if it does not go as planned?”
