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 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 the Visibility:
   Public — customers can see the maintenance on public status surfaces, and linked components can show maintenance impact once the window starts.
   Internal — only your team can see the maintenance. It does not appear on the public status page, embed, or KB portal, and it does not change public component status when the window starts.
4. 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).
5. Optionally set an end time. If you set one, it must be after the start.
6. 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.
7. Link the components this work will affect, the same way you would on a regular incident.

Once created, the maintenance sits in planned 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. For a public 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.

For an internal maintenance, linked components stay internal to the team view. Even when the window activates, the maintenance does not change public component status or publish impact to customer-facing status surfaces.

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 planned to in progress.
• For public maintenance, every linked component that’s currently operational is switched to a maintenance status.
• For internal maintenance, linked components are not changed on the public status page.
• A system update is posted noting that the maintenance has started, which is also what triggers the notification to subscribers for public maintenance.

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 completed, restoring any components it changed back to operational.

What customers see

What customers see depends on the maintenance visibility.

For public maintenance:

• 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.

For internal maintenance, customers don’t see the maintenance on the status page, embed, or KB portal. The maintenance is visible to your team only, and activating it does not change public component status.

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

See also

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