It's Sunday, 01:00. The database upgrade you announced two weeks ago is under way. Right on schedule, your monitoring does exactly what it was built to do: it pages the on-call engineer about the outage you are causing on purpose.
Every team that runs planned work hits this, and most settle on one of two bad fixes:
- Pause the monitors. The pages stop — and so does the data. If the upgrade breaks something subtle, you find out after you've resumed monitoring and told everyone it went fine. And the pause has no end time: forgotten paused monitors are how "why didn't we get alerted?" postmortems start.
- Eat the alerts. Let the pages fire and tell everyone to ignore them. Congratulations: you've just trained your team that alerts are sometimes noise. That lesson sticks exactly until the night a real incident lands during a maintenance window.
There's also a third, quieter failure: the SLA lie. If planned downtime counts against uptime, your numbers look worse than your reliability. If you silently delete it from the record, your numbers are fiction. Both destroy trust in the report — just with different audiences.
A proper maintenance window fixes all three at once. Here's the shape of it.
Rule 1: never stop the checks
The whole point of maintenance is that you're changing something — which is precisely when you most want measurements. A maintenance window should suppress the alerts, not the monitoring: checks keep running the entire time, so when the migration finishes at 02:40 you can look at the graph and know the service came back healthy, not hope it did.
In WatchFor, that's the default behaviour of a window: covered monitors keep checking on their normal schedule; only the notifications stop. The monitor carries a neutral Maintenance badge alongside its real status — if the service is down mid-window, the dashboard says so. You're silencing your phone, not your eyes.
And if something genuinely unexpected breaks during the window, the incident is still recorded in history with its full timeline. It doesn't page anyone and doesn't dent uptime — but it's there for the morning review, because "the upgrade went fine" should be a verified claim.
Rule 2: planned time is neutral time — and says so
The honest way to handle planned downtime in an SLA is to treat it as neither up nor down. The window's minutes are excluded from the calculation — and the exclusion is printed on the report: "99.98% — excludes 2h of scheduled maintenance."
That last part is the difference between an honest report and a doctored one. Anyone reading the number can see exactly what was excluded and why. Customers on your status page see the same story: maintenance is announced, tracked, and visibly distinct from an outage.
Both effects are toggles per window, because reality has edge cases: a "watch closely" window might keep alerts on while still marking the time as planned, and a window you only use for announcements might touch nothing at all.
Rule 3: one source of truth, announced automatically
Planned work generates two artifacts that always drift apart when they're managed separately: the suppression (in the monitoring tool) and the announcement (on the status page). Teams schedule one and forget the other — or worse, retroactively label an unplanned outage as "maintenance" to protect the uptime stat.
The fix is structural: the maintenance window is the single place where planned work exists, and the status page announcement is generated from it. When you schedule a window with "announce on status pages" on:
- a "Scheduled maintenance" notice appears on your chosen status pages ahead of time,
- it automatically lists the affected components — derived from which monitors the window actually covers, so the announcement can't disagree with reality,
- it tracks the lifecycle on its own: Scheduled → In progress → Completed.
Because the announcement flows from the window and not the other way around, there's no button to declare something "maintenance" after it already broke. Planned means planned in advance — your status page history stays trustworthy.
(Need to announce work on something you don't monitor — a payment provider's downtime, an office move? An announcement-only window with no monitors posts and tracks the notice without suppressing anything.)
The mechanics that make it usable
The rules above are the philosophy. Day-to-day, the details decide whether people actually use the feature or go back to pausing monitors:
Target by tag, not by checkbox archaeology. A window can cover specific monitors — or a tag. "Everything tagged backend, nightly at 02:00" keeps covering new monitors as you add them. No stale checklist to maintain.
Recurrence that survives daylight saving. Daily, weekly and monthly windows are scheduled in the window's own timezone and keep their local time across DST changes — your 02:00 batch window doesn't silently become a 01:00 one in March.
Reality rarely matches the calendar. A running window can be driven by hand: start now when the deploy begins early, extend by +15m/+30m/+1h when the migration runs long (the suppression and the public notice move together), complete now when you finish ahead of schedule and want alerting back immediately.
Planned time looks different in history. In uptime heatmaps, maintenance hours are drawn with a distinct hatched texture rather than pretending to be green or red — and if a real incident overlapped the window, the incident wins the pixel. The visual record keeps the same honesty as the numbers.
Pause vs. maintenance, in one table
| Checks | Alerts | Uptime/SLA | Ends | |
|---|---|---|---|---|
| Pause | stopped | none (no data) | gap in the record | when someone remembers |
| Maintenance window | keep running | suppressed | excluded, disclosed | on schedule (or one click) |
Pause is for monitors you're abandoning for a while. Maintenance windows are for work with a start, an end, and an audience.
The 2-minute setup
For the classic case — a weekly deploy window:
- Alerting → Maintenance → New maintenance window.
- Name it, pick the monitors or a tag, set Weekly, Sunday 01:00, 1 hour in your timezone.
- Leave both effects on (suppress alerts, exclude from SLA).
- For one-time windows, tick the status pages that should announce it.
From then on the window activates and lifts itself. Nobody gets paged for the deploy, the SLA report discloses the exclusion, customers see a proper notice — and if the deploy actually breaks something, the checks that never stopped will tell you.
Maintenance windows are part of WatchFor's incident tooling — the docs cover every option, and every plan includes at least one window to start with.