What a maintenance window suppresses
A maintenance window never stops a monitor from checking. What it changes is whether a failing check alerts
anyone and whether the downtime counts against the monitor’s uptime. You choose each one per monitor, with the
Alerts and Stats tiles in the editor (suppress.alerts and suppress.stats in the API).
The two choices
Section titled “The two choices”| Tile (API field) | While the window runs | Typical use |
|---|---|---|
Alerts (suppress.alerts) |
No down notification is sent for the monitor - not by email, SMS, voice, messengers or classic webhook contacts. Escalation steps do not fire. Alerts from the monitor’s attached sub-checks (certificate, domain, blacklist, Web Risk) are held back too. | Every planned change where people should not be paged. |
Stats (suppress.stats) |
The time is counted as maintenance, not downtime. It is left out of the monitor’s uptime percentage, SLA figures and reports. | Planned downtime that should not lower your published uptime. |
Turn on both for a full “this is planned, ignore it”; turn on only Alerts when you want to stay quiet but keep the numbers honest - for example for a dependent service you are not sure will survive the change.
A covered monitor must have at least one of the two on. When you create a window through the API with monitorIds
and no suppress object, Alerts is on and Stats is off.
What still happens
Section titled “What still happens”- Checks run on schedule from the usual locations, and every result is recorded in the check log.
- Incidents are still recorded. A down episode that happens during the window is stored like any other, marked
as under maintenance. The
incident.openedwebhook event still fires, withunderMaintenance: true, so an integration can tell the two apart. - The monitor’s state reads
maintenance. While its latest check ran inside a window, the API reports the monitor’sstateasmaintenancerather thanupordown(filter withGET /monitor?state=maintenance). - Monitors outside the window are unaffected, even when they check the same server.
Overlapping windows
Section titled “Overlapping windows”When several windows cover the same monitor at the same moment, their choices add up: if any active window suppresses alerts, alerts are suppressed; if any suppresses stats, the time counts as maintenance.
When the window ends
Section titled “When the window ends”Suppression stops the moment the window’s end time passes:
- A monitor that is still down at that moment sends one down alert straight away, to the contacts that would have been alerted. From then on it follows normal down detection and alerting, including “still down” reminders.
- Downtime after the end counts against uptime again.
- A monitor that recovered during the window sends no recovery alert for an outage nobody was told about.
If the work might run long, extend the window before it ends (change Ends or use Quick add), or expect that one alert.
A maintenance.ended webhook event fires when a window ends on schedule (endedEarly: false) or is cancelled while
active (endedEarly: true). Cancelling an active window - deleting it, or turning Window active off - makes its
monitors alert again at once.
How it shows in uptime numbers
Section titled “How it shows in uptime numbers”With Stats on, the covered time is removed from the calculation rather than counted as up or down:
uptime % = time up / (time measured - time under maintenance)On a status page, days that contain maintenance for a component are drawn in blue on its uptime bars, but only when no other component had a real problem that day - blue never hides a real outage. See Uptime percentage and SLA and Show maintenance on your status page.
Timing
Section titled “Timing”Changes you make to a window - creating, editing, pausing, cancelling - reach the checking engine within about a minute. Save a window at least a minute before the work starts.