Maintenance windows

Planned work generates the same alerts as an outage. A maintenance window tells AlertKick that a burst of alerts over a known period is expected: the alerts are still created and still visible, they simply do not notify anyone and do not start an escalation chain.

The alternative - pausing monitors or disabling a policy for the evening - loses the record of what happened and, more often, gets forgotten in the “on” position afterwards. A window has an end time, so it closes itself.

Creating a window

Admin, then Maintenance Windows, then Add. A window needs a name, a start, an end, and a scope:

Scope	Silences
Everything	Every alert source and monitor in the account
Selected integrations	Alerts arriving from the alert sources you pick
Selected monitors	Alerts raised by the monitors you pick

Windows can be up to 90 days long. Start times in the past are allowed, so you can open one the moment work starts rather than backdating a plan.

Scope tightly where you can. A window scoped to the two integrations that will be noisy during a database migration keeps the rest of the estate paging normally, which matters if something unrelated breaks while everyone is watching the migration.

What actually happens to a covered alert

An alert that arrives inside an open window:

• is still created, with its severity, source, and payload intact
• is stamped with the window that covered it
• gets a “Suppressed by Maintenance Window” activity naming the window and when it ends
• sends no notifications - no email, Slack, SMS, push, or anything else
• starts no escalation - no levels are scheduled, so nothing can climb the chain later

Both paths into an alert respect the window: alerts pushed in from an inbound integration and alerts raised by AlertKick’s own monitors.

Because the alerts still exist, the maintenance period is auditable afterwards. “Nothing paged us between 22:00 and 02:00” and “nothing happened between 22:00 and 02:00” are very different statements, and only the second one is a problem.

After the window closes

Nothing is replayed. New alerts notify normally the moment the window ends, but alerts that were suppressed stay suppressed - the decision was made when they were created and is not revisited.

That has one consequence worth planning around. Repeat triggers for a problem that already has an open alert are deduplicated: they bump the trigger count and add a “triggered again” entry rather than paging a second time. So an alert first raised inside the window, still open when the window closes, will not start paging on its own - the source keeps deduplicating into it.

If a problem is still live at the end of planned work, resolve the suppressed alerts. The next trigger then creates a fresh alert outside the window and escalates normally. Reviewing and clearing what the window absorbed is worth doing anyway, and it is what re-arms the pager.

Working with the alert list

Suppressed alerts appear in the alert list like any other, so the usual filters and bulk actions apply. Resolving them in bulk after a planned migration is the common cleanup - see working with alerts.

API

The windows are CRUD under /api/v1/maintenancewindows:

curl -X POST https://<subdomain>.alertkick.com/api/v1/maintenancewindows/create \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "display_name": "DB migration",
    "start": "2026-09-04T22:00:00Z",
    "end": "2026-09-05T02:00:00Z",
    "scope": "sources",
    "source_uuids": ["<alert-source-uuid>"],
    "note": "Planned schema change, change ticket CHG-2291"
  }'

GET /api/v1/maintenancewindows lists them; /update and /delete take the window uuid. Scripting the window into a deploy pipeline is the reliable way to make sure it is opened before the work starts and not left open afterwards.

Related but different

• SSH lockdown windows control who may log in to a host. Maintenance windows here control who gets paged. Opening one does not open the other.
• Change tracking records declared changes and their scope for the compliance trail. A maintenance window is about notification noise, not evidence.

Troubleshooting

An alert paged during a window

• Check the window’s scope: a window scoped to monitors does not cover alerts arriving from an integration, and the reverse
• Check the start and end against the alert’s timestamp in UTC
• Confirm the window has not been deleted; deletion takes effect immediately

Alerts stayed silent after the window ended

• Confirm no second window is open over the same scope
• Check the alert is genuinely new rather than a repeat trigger on an alert that was already open and suppressed

Next steps

• Set up the chain that runs when there is no window open: escalation policies
• Give the rota a break for known-noisy work instead of muting people: roster management

Need help with maintenance windows? Contact support at support [at] alertkick [dot] com.