Maintenance windows

A maintenance window is a period of planned work during which Notifly does not wake your team: a deploy from 02:00 to 04:00, a weekly database upgrade on Tuesdays, a weekend migration.

Go to Monitoring → Maintenance windows (or Cmd/Ctrl+K → “Maintenance windows”). Channels and monitors in an active window get a “Maintenance” badge.

What a window covers

Channels — all monitors and heartbeats of these channels and all messages in them. “Include nested channels” extends the window to the whole subtree.
Individual monitors — specific monitors/heartbeats, even if their channel is not in the window.

You can only cover your own channels and monitors of your channels that you created yourself. A window holds up to 200 channels and up to 200 individual monitors; the name is up to 100 characters. A disabled window (“Window enabled” unchecked) has no effect.

Schedule

Type	Fields
One-time	`startsAt` – `endsAt` (at most 31 days)
Weekly	weekdays (`days`, ISO: 1 = Mon … 7 = Sun; by start day), `start`–`end` in a time zone; crossing midnight is OK

The end of a window is exclusive: a 02:00–04:00 window is over at 04:00.

What happens while a window is active

Where	Effect
Monitors & heartbeats	Checks keep running and are recorded, but the down alert is deferred. If the problem persists after the window, the very next check sends it
Channel messages	Not escalated to external channels (email, SMS, calls, messengers, webhooks) — neither during nor after the window
Push to devices	Delivered silently: the server sets the `notifly::delivery` flag (see below)
Status page	The component shows “Scheduled maintenance”, the banner says “Scheduled maintenance in progress”; failed checks inside the window don’t hurt 30/90-day uptime
Incidents	No automatic status-page incident is opened inside the window; if the service is still down afterwards, it opens together with the deferred alert

Details:

You never get “Recovered” without “Down”: if a monitor went down and came back inside the window, you receive no message at all.
A heartbeat whose ping goes overdue inside a window does not switch to alerting: the check is moved to the end of the window. If a ping arrives, the heartbeat quietly returns to ok; if not, a normal alert is sent after the window. Such a miss is recorded in history once per window and doesn’t hurt uptime.
Content, workflow and browser workflow monitors don’t report changes inside the window and don’t move their baseline: after the window the values are compared with the pre-maintenance snapshot, so a temporary “under maintenance” page won’t alert.
In uptime, a failure inside the window is excluded from both the numerator and the denominator. A day whose failures all fell into a window gets its own colour.

Silent delivery: `notifly::delivery`

Every message created in a channel inside an active window gets this in extras:

{
  "notifly::delivery": {"silent": true, "reason": "maintenance"}
}

Clients show such a notification without sound, vibration or a heads-up banner — but they do show it (unlike the service flag notifly::silent). See the WebSocket protocol for details.

REST API

Method and path	Description
`GET /maintenance-window`	Your windows (with computed fields)
`POST /maintenance-window`	Create
`GET /maintenance-window/{id}`	A single window
`PUT /maintenance-window/{id}`	Replace the window’s fields
`DELETE /maintenance-window/{id}`	Delete (`204`)

# One-time window for a channel and all of its children
curl -X POST -H "X-Notifly-Key: $TOKEN" -H "Content-Type: application/json" \
  https://host/maintenance-window \
  -d '{"name":"Release 2.4","channelIds":[12],"includeSubtree":true,"monitors":[],
       "schedule":"once","startsAt":"2026-10-02T23:00:00Z","endsAt":"2026-10-03T01:00:00Z",
       "enabled":true}'

# Weekly window for a single HTTP monitor
curl -X POST -H "X-Notifly-Key: $TOKEN" -H "Content-Type: application/json" \
  https://host/maintenance-window \
  -d '{"name":"DB backup","channelIds":[],"monitors":[{"kind":"http_monitor","id":345}],
       "schedule":"weekly","timezone":"Europe/Berlin","days":[2],"start":"02:00","end":"04:00",
       "enabled":true}'

Monitor kinds (kind): monitor, http_monitor, content_monitor, port_monitor, workflow_monitor, browser_workflow_monitor, heartbeat.

The response adds computed fields: active — the window is in progress; nextStart/nextEnd — the current (if active) or next occurrence; coveredChannelIds — covered channels with the subtree expanded.

Codes: 400 — validation error, someone else’s channel or monitor; 403 — limit (100 windows), a read-only or channel-scoped API token; 404 — someone else’s or a missing window.