Maintenance Window: Plan One Without False Alerts
A maintenance window is announced downtime you control. Here is how to size it, suppress the right alerts, and keep the data you will need later.
A maintenance window is a block of time you announce in advance, during which a service may be slow or offline while you patch, migrate or deploy. The work itself is the easy part. The hard part is making sure nobody is surprised: not your users, not the on-call engineer, and not the availability figure you report at month end.
What actually goes into a maintenance window?
Four fields, and most teams only fill in three. A window needs a start time, a duration, the list of affected components, and an explicit decision about alerting. Wikipedia's definition covers the first three and stops there, which is why the fourth keeps getting improvised at 02:00 by whoever is awake.
| Field | What to write | Failure if you skip it |
|---|---|---|
| Start | An absolute UTC timestamp | Colleagues in other regions arrive an hour late |
| Duration | Longer than the work, with a hard stop | The window never formally ends |
| Components | The specific services users touch | Support cannot answer "is this related?" |
| Alerting | Suppress, pause, or leave alone | The pager fires on your own deploy |
Write the maintenance window down somewhere your support team can actually read it. A calendar invite to the infrastructure channel is not an announcement, and neither is a thread nobody outside the team is in.
How long should a maintenance window be?
Longer than the work and shorter than the patience of your users. We prefer roughly three times the expected duration for anything that touches data. A schema migration you have rehearsed at 25 minutes gets 90 minutes, because the rollback is the part you have not rehearsed.
Two habits make that number defensible. Pick the hour from your own traffic graph rather than from folklore, because "Sunday 03:00" is only quiet if your users sit in one hemisphere. Then publish an end time you can hit, since an overrun costs far more trust than a window that looked generous on the calendar.
Suppress the alert, do not pause the check
This is the distinction between a calm window and a blind one. Suppressing alerts stops the pager. Pausing the check stops the data. They are not the same decision, and several tools only offer the second one.
SolarWinds Pingdom's own documentation says its maintenance feature "pauses both the monitoring and alerting" (SolarWinds docs, as of September 2026). AWS takes the scheduling-only view instead: Systems Manager Maintenance Windows define when disruptive tasks run and leave observation to other services entirely.
In our testing the paused-check approach hurts twice. You lose the timing waterfall for exactly the period you will want to inspect afterwards. You also leave a gap in the availability calculation, because minutes with no samples are not the same as minutes that failed. A maintenance window that records a flat line of errors is honest. One that records nothing at all is a hole in your history.
Scheduling maintenance without paging anyone
The maintenance window sequence we use has five steps, and the first two happen before it opens.
- Announce it on the status page with the affected components listed, at least 24 hours ahead.
- Route the affected monitors to a quiet channel such as email, and off SMS or voice.
- Do the work, keeping the checks running so you can see the shape of the disruption.
- Prove the service is healthy again from outside your own network.
- Close the window and restore the normal alert route.
Step four is the one people skip. A deploy that returns 200 on localhost can still fail from Sydney. A stale certificate chain or an unpropagated DNS record will do it, and neither is visible from the machine you deployed on.
# prove the service is actually back before you close the window
curl -s -o /dev/null \
-w 'status=%{http_code} dns=%{time_namelookup}s tls=%{time_appconnect}s total=%{time_total}s\n' \
https://example.com/health
Run that from more than one place. Uptime Room probes from six regions as of September 2026, and Los Angeles agreeing with Singapore is a far stronger signal than either on its own. Region codes and probe egress IPs are published on the probe IPs page, which matters when the work involves a firewall or allowlist change.
What your status page should say
Users do not want your runbook. They want three sentences: what is affected, when it starts and ends, and whether they need to do anything. More than that is noise. Less than that generates the support tickets you were trying to avoid.
A status page with components, subscriber emails and an RSS feed turns one announcement into something people can follow without refreshing a tab. The monitoring and content APIs let you script that announcement from the same pipeline that runs the migration. That keeps the maintenance window on the page identical to the one in your change ticket.
Does planned work count against your uptime?
It depends on who is counting, and you should settle the question before you need the answer. Most teams exclude announced work from their reported availability and count everything else. That convention only holds if the announcement went out first, and if the window covered the components it claimed.
Write the rule into your own definition of the metric, then apply it identically every month. Two numbers beat one here. Raw availability counts every failed minute. Adjusted availability excludes the announced windows, and the gap between the two tells you how much of your downtime you actually chose.
Response-time history keeps p50, p95 and p99 per monitor, for one month on the free plan and a year on Individual as of September 2026. That record is what lets you separate the two figures later without guessing. A check that kept running through the work is the only evidence that the disruption stayed inside the hours you published.
Common mistakes
Backdating the window. Announced maintenance usually sits outside the availability calculation, but only when it was announced before it began. Moving a window afterwards to rescue a monthly number is how a reliability metric quietly stops meaning anything to anyone.
Suppressing alerts for the whole service. Suppress the components you are touching and nothing else. If checkout is untouched and it breaks during your database work, you badly want that alert. The four golden signals still apply inside the window, and latency is usually the first to move.
Expecting the window to shrink the blast radius. It is a communication tool, not a safety mechanism. It will not make a bad migration reversible, and it will not stop an unrelated probe blip from waking someone at 04:00. That second problem is fixed by cross-region quorum confirmation, not by scheduled maintenance.
A good maintenance window is boring. Announce it early, size it generously, scope it to the components you are genuinely touching, and keep watching the whole way through. You can plan one on the free plan, which covers 10 monitors at a one-minute check interval as of September 2026. When the window closes, the history is still there to prove it went the way you said it would, so start free and keep it.
FAQ
A maintenance window is a period designated in advance by technical staff, during which preventive work such as patching, migrating or deploying may disrupt a service. A complete definition also names the affected components and says what happens to alerting while the work runs, because that last decision is what stops the on-call engineer being paged by your own deploy.
Most planned windows run between 30 minutes and four hours, and the safe rule is to publish roughly three times the rehearsed duration of the work. A migration you have timed at 25 minutes deserves 90 minutes, because the rollback path is the part nobody rehearses. Overrunning a short window damages trust more than announcing a generous one.
In PagerDuty a maintenance window temporarily disables one or more services so incidents are not triggered for them during planned work, according to its own support documentation as of September 2026. The idea is the same everywhere: stop the pager without pretending the underlying work is invisible to the people watching your service.
Yes. Suppressing the alert and pausing the check are different decisions, and only the first one is usually wanted. A paused check records nothing, so you lose the timing data for the exact period you will want to review, and the availability calculation skips those minutes instead of counting them honestly as failures.
Related reading
- Cross-Region Quorum: How Confirmation Stops False Alerts - Cross-region quorum means a target is only called down once probes in more than one region agree. Here is the voting rule, its cost and its limits.
- Golden Signals: The Four SRE Metrics That Matter - Golden signals are latency, traffic, errors and saturation - the four metrics Google's SRE book says to watch when you can only watch four.