Schedule a planned maintenance

Not every disruption is unplanned. If you know work is coming — a database migration, a deploy window, planned downtime for a component — you can tell customers about it ahead of time instead of waiting until the work has already started. That’s what a planned maintenance is: an incident announced in advance, with a scheduled window that opens and closes on its own.

Create a planned maintenance

1. Open New incident as you normally would.
2. Choose Schedule for later. This marks the incident as a maintenance rather than a regular incident.
3. Set a start time. This is required, and it can’t be set in the past (a small clock-skew grace is allowed, so you don’t get blocked by a few seconds’ drift between your browser and the server).
4. Optionally set an end time. If you set one, it must be after the start.
5. Add a title and, if you like, a message describing the work. The message is optional — you can announce a maintenance with just a title and a window.
6. Link the components this work will affect, the same way you would on a regular incident.

Once created, the maintenance sits in scheduled status until its window opens.

Linking components doesn’t publish impact yet

This is the part that’s different from a normal incident. When you attach a component to a regular incident, that component’s status changes immediately and the status page reflects it right away.

A planned maintenance works differently: linking a component only associates it with the maintenance. The component’s public status is untouched, and the status page keeps showing it as normal, until the window actually activates. This is intentional — a maintenance that hasn’t started yet shouldn’t paint the status page as degraded or “under maintenance” days before anyone is affected.

Because of this, while a maintenance is still scheduled, you can link components but you can’t hand-set their status the way you would on a live incident — that control opens up once the window is running.

What happens when the window opens

You don’t have to do anything for a scheduled maintenance to start. A background check activates every window whose start time has passed, roughly once a minute. When that happens:

• The incident moves from scheduled to in progress.
• Every linked component that’s currently operational is switched to a maintenance status.
• A system update is posted noting that the maintenance has started, which is also what triggers the notification to subscribers.

If a linked component is already in a worse state because of a different, unrelated incident — say it’s showing a major outage — activation leaves it alone. A planned maintenance window is never allowed to paint over a real, ongoing outage on the status page.

Managing a scheduled maintenance

Before its window opens, a maintenance lives in the Planned tab of the incident list, alongside any other maintenance you have upcoming. Open it to reach the planned-window panel, where you have three actions:

• Start now — activate the window immediately instead of waiting for the scheduled start. This applies the same component impact and posts the same “maintenance has started” update as an automatic activation would.
• Change time — move the start and/or end. You can reschedule either edge of the window independently; changing just the end time doesn’t require re-entering the start.
• Cancel — call off the maintenance before it starts. A cancelled maintenance never activates and never touches component status.

Once a window has activated, it’s no longer “planned” — it’s a running maintenance, managed like any in-progress incident. You post updates, and you complete it the same way you resolve a regular incident: the maintenance simply moves to resolved, restoring any components it changed back to operational.

What customers see

• Status page — scheduled maintenances that haven’t started show up in a dedicated planned section, listing the upcoming window. Once the window activates, the maintenance moves out of the planned section and reads as in-progress, with its components shown under maintenance.
• Embed — the incidents embed mirrors the same scheduled-vs-in-progress distinction.
• KB portal — the system-status block in the portal reflects the same state: a heads-up for scheduled work, and an active maintenance indicator once the window opens.

In every surface, the rule is the same one that governs the incident record itself: nothing about a scheduled maintenance affects the “current” system status until its window has actually started.

See also

• The Incidents module
• Create an incident
• Incident statuses reference