Maintenance windows

Schedule maintenance periods to suspend alerts: creation, start, end and cancellation.

What it's for

A maintenance window declares a planned period during which interventions are expected. Its main effect: suspend alerts on the affected hosts and checks, in order to avoid an avalanche of notifications during a deliberate operation (deployment, restart, migration…). You also choose whether or not to inform your subscribers (status page).

The window model

Field	Type	Required	Description
`id`	uuid	(generated)	Unique identifier.
`title`	string	✅	Maintenance title.
`description`	string	—	Operation details.
`start_time`	date (RFC3339)	✅	Planned start.
`end_time`	date (RFC3339)	✅	Planned end (must be after the start).
`suppress_alerts`	boolean	—	Suspend alerts during the window. Default: `true`.
`notify_subscribers`	boolean	—	Inform subscribers. Default: `true`.
`affected_checks`	array	—	Affected checks.
`affected_hosts`	array	—	Affected hosts.
`status`	string	(managed)	`scheduled`, `active`, `completed` or `cancelled`.

Lifecycle

scheduled ──(start)──► active ──(end)──► completed
    │
    └──(cancel)──► cancelled

A window is created as scheduled. You can start it (→ active), end it (→ completed) or cancel it (→ cancelled). Only a scheduled window can be started, and only an active window can be ended.

Using it from the portal

The Maintenance section distinguishes upcoming windows from past windows. You can schedule a window, start it, end it or cancel it, and choose whether it suspends alerts and notifies subscribers.

Listing and viewing: all roles. Create, edit, start, end, cancel: owner and admin.

Using it through the API

List

GET /api/v2/maintenance-windows

curl -s https://api.secumon.secuaas.ovh/api/v2/maintenance-windows \
  -H "Authorization: Bearer $SECUMON_TOKEN"

{
  "count": 1,
  "maintenance_windows": [
    {
      "id": "f0f1f2f3-1234-4abc-9def-aabbccddeeff",
      "title": "Application update web-prod-01",
      "start_time": "2026-06-24T02:00:00Z",
      "end_time": "2026-06-24T03:00:00Z",
      "suppress_alerts": true,
      "notify_subscribers": true,
      "status": "scheduled"
    }
  ]
}

Create

POST /api/v2/maintenance-windows — title, start_time and end_time required (RFC3339, end after start).

curl -s -X POST https://api.secumon.secuaas.ovh/api/v2/maintenance-windows \
  -H "Authorization: Bearer $SECUMON_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Application update web-prod-01",
    "description": "Deployment of version 2.4, service restart.",
    "start_time": "2026-06-24T02:00:00Z",
    "end_time": "2026-06-24T03:00:00Z",
    "suppress_alerts": true,
    "notify_subscribers": true,
    "affected_hosts": ["8f3b1c2a-2d44-4e1a-9b77-0a1b2c3d4e5f"]
  }'

Response: 201 Created with the window in scheduled status.

View and edit

# Detail
curl -s https://api.secumon.secuaas.ovh/api/v2/maintenance-windows/f0f1f2f3-1234-4abc-9def-aabbccddeeff \
  -H "Authorization: Bearer $SECUMON_TOKEN"

# Edit (partial fields)
curl -s -X PUT https://api.secumon.secuaas.ovh/api/v2/maintenance-windows/f0f1f2f3-1234-4abc-9def-aabbccddeeff \
  -H "Authorization: Bearer $SECUMON_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "end_time": "2026-06-24T03:30:00Z" }'

Start, end, cancel

# Start (scheduled → active)
curl -s -X POST https://api.secumon.secuaas.ovh/api/v2/maintenance-windows/f0f1f2f3-1234-4abc-9def-aabbccddeeff/start \
  -H "Authorization: Bearer $SECUMON_TOKEN"

# End (active → completed)
curl -s -X POST https://api.secumon.secuaas.ovh/api/v2/maintenance-windows/f0f1f2f3-1234-4abc-9def-aabbccddeeff/end \
  -H "Authorization: Bearer $SECUMON_TOKEN"

# Cancel (→ cancelled)
curl -s -X POST https://api.secumon.secuaas.ovh/api/v2/maintenance-windows/f0f1f2f3-1234-4abc-9def-aabbccddeeff/cancel \
  -H "Authorization: Bearer $SECUMON_TOKEN"

start and end return the updated window; cancel returns 204 No Content. Attempting to start a window that is not scheduled, or to end a window that is not active, returns a 400 error.

Use cases

Planned deployment: create a window covering the operation, with suppress_alerts: true, so as not to wake the on-call person.
Proactive communication: leave notify_subscribers: true to inform your users through the status page.
Extended intervention: adjust end_time mid-operation if the maintenance overruns.

Tips

Target affected_hosts / affected_checks precisely to suspend only what is really impacted, and keep monitoring the rest.
Remember to end the window as soon as the operation is over: this restores alerts earlier if you finished ahead of schedule.
A window started manually (/start) is useful when the intervention begins before the planned time.

On this page