Maintenance windows

A maintenance window is a time range during which monitors with matching tags, or the monitors of chosen services, don’t page. Checks still run and failures are still recorded, but they don’t reach anyone while the window is active.

Use maintenance windows for scheduled deploys, database migrations, vendor maintenance and batch jobs whose spikes are expected.

Two types

One-time

A single starts_at / ends_at pair, for one specific deploy or operation.

{
  "name": "Friday API deploy",
  "tags": ["service:api"],
  "schedule_type": "one_time",
  "starts_at": "2027-01-15T14:00:00Z",
  "ends_at": "2027-01-15T14:30:00Z"
}

Recurring

A recurrence rule, daily (the same window every day) or weekly (the same window on chosen days):

{
  "name": "Nightly batch ETL",
  "tags": ["service:etl"],
  "schedule_type": "recurring",
  "timezone": "America/Los_Angeles",
  "recurrence": {
    "type": "daily",
    "start_time": "02:00",
    "end_time": "03:00"
  }
}

{
  "name": "Sunday maintenance window",
  "tags": ["env:prod"],
  "schedule_type": "recurring",
  "timezone": "UTC",
  "recurrence": {
    "type": "weekly",
    "days": ["sunday"],
    "start_time": "02:00",
    "end_time": "04:00"
  }
}

start_time and end_time are 24-hour HH:MM in the window’s timezone (defaults to UTC). See recurring windows.

Windows by service

A window can name services in service_ids instead of, or as well as, tags. Every monitor and alert rule linked to those services is covered, whatever its tags, including monitors you add to the service later:

{
  "name": "Checkout deploy",
  "service_ids": ["<service-id>"],
  "schedule_type": "one_time",
  "starts_at": "2026-05-10T14:00:00Z",
  "ends_at": "2026-05-10T14:30:00Z"
}

A window needs tags, services or both.

How tags match

A monitor is silenced when its tags overlap with an active window’s tags, meaning at least one tag appears in both lists.

There is no wildcard tag. To silence everything, give every monitor a shared tag (for example env:prod) and put that tag on the window.
A monitor with no tags never matches by tag; put its service on the window instead.

Useful patterns: service:<name> for everything in a service, env:<name> for an environment, type:cron for all cron checks.

What “silenced” means precisely

Suppression applies to HTTP monitors, heartbeats, browser checks, TLS certificate and page speed checks, and alert rules, including RUM issue alerts. TLS and page speed checks match by their HTTP monitor’s tags; all of them match by the service they are linked to. Each RUM issue is held on its own. Domain registration and DNS record alerts are never held. While a matching window is active:

Failure notifications are held, not dropped. They are stored and re-evaluated when the window’s current occurrence ends, so a monitor that is still down after the window pages then.
Recovery notifications are suppressed and clear the held failure for that monitor, so a blip fully inside the window pages no one.
Auto-created incidents wait. A monitor that fails inside the window opens its service’s incident when the window ends, if it is still failing then; a blip that recovers inside the window never opens one. An incident that was already open keeps its escalation paused until the window ends.
Ending a window early releases what it held. Deleting a window, moving its end earlier or removing tags or services sends the alerts it no longer covers within a minute, unless another active window still covers them.
The window shows what it holds. The dashboard’s window form lists the monitors the window matches and how many alerts are held for each right now (GET /maintenance_windows/{window_id}/coverage in the API).
Status pages keep showing live status unless you also publish a status page maintenance entry.