Events API

Maintenance windows

Schedule quiet time that records incidents while pausing paging for the services in scope.

Upgrading a database on Saturday night? You know alerts will fire, and you don’t want them paging anyone. A maintenance window is scheduled quiet time: incidents still open and record everything, but the paging politely waits.

Nothing is thrown away. When the window ends, any incident that’s still unresolved starts paging normally. You get silence during planned work without ever losing the record of what happened.

Before you begin

You need a WarnFire workspace with a working response path and tenant-owner or tenant-administrator access. If the window covers one service, confirm the service exists and that you can identify it before scheduling the window.

Schedule one

1. Open Configuration → Maintenance.
2. In Schedule maintenance, fill in:
   • Name — e.g. Database upgrade.
   • Scope — one service, or All services.
   • Starts and Ends — in your local timezone (shown under the form).
   • Reason — optional, but future-you will thank present-you.
3. Decide about the “Allow explicitly requested critical-event overrides” checkbox (explained below — leaving it on is recommended).
4. Press Schedule maintenance.

Windows move through simple states: scheduled → active → completed. You can edit a scheduled window, and Cancel one at any point — if you cancel an active window, paused incidents resume paging within about a minute.

Only the services you scoped it to

A window covers one service, or All services — whatever you chose when you created it. A window on your checkout service does not quiet your database. Incidents outside the selected scope continue through their configured escalation policies. That scope lets you quiet planned work without pausing unrelated services.

What responders see

An incident opened during maintenance is clearly labeled — “Paging paused for maintenance” with the exact time escalation resumes — in the console and the mobile app. Anyone looking knows the alarm isn’t broken; it’s deliberately on hold.

Critical alerts do not break through

This is the part worth being clear about, because people assume the opposite: a critical alert does not override a maintenance window. That is the whole point of the window. You are taking things down deliberately, so things will break, and the most serious-looking alerts are precisely the ones you expect. A window that let criticals through would page you for the work you are doing.

There is one narrow exception, and it is off unless you turn it on twice.

The emergency escape hatch

What if something truly serious breaks during your maintenance window — unrelated to the planned work?

If the window allows overrides (the checkbox above), a monitoring system can mark an event as too important to hold by sending "maintenance_override": true in the payload of a critical-severity event. That one event ignores the quiet time and pages immediately.

Both halves must agree: the window must allow overrides, and the event must be critical and explicitly ask. An ordinary warning can never barge through.

Asking requires the maintenance_override field in the payload, so it works from the Events API and from the generic webhook adapter , which accepts the same event shape. The fixed-format provider adapters — Prometheus Alertmanager, Datadog, and the rest of the webhook adapters — translate a provider’s own payload and have no place to carry the field, so an incident they open during a window waits for the window to end. That’s the safe default: quiet time stays quiet unless something deliberately says otherwise.

{
  "integration_key": "YOUR-INTEGRATION-KEY",
  "event_action": "trigger",
  "dedup_key": "primary-db/replication-broken",
  "payload": {
    "summary": "Replication to standby has stopped entirely",
    "source": "db-monitor",
    "severity": "critical",
    "maintenance_override": true
  }
}

Verify it worked

1. Confirm the window appears under Configuration → Maintenance with the intended service scope, local start time, local end time, and current state.
2. During the active window, send a coordinated test event for a service in scope. Confirm that the incident opens and shows Paging paused for maintenance with the expected resume time.
3. Confirm that a service outside the scope continues paging normally. Skip this step for an All services window.
4. Resolve the test incident before ending the exercise. If you deliberately test cancellation or expiration with an unresolved incident, coordinate with the on-call responder because paging resumes.

Next steps

Use the trigger example and resolve example to construct the controlled events for the verification above.