# Maintenance

A planned maintenance window.

Source: https://statusdashboard.com/docs/events/types/maintenance

Use a maintenance event for a planned window when you need to announce work that may affect services. Set the scheduled start and end in the admin console, optionally enable automatic start and stop, and keep subscribers informed through the maintenance workflow and timeline.

***

## Times
A maintenance event represents a planned maintenance window. Maintenance events:

* Require a **scheduled start time** and **end time** — these represent the planned window, not actual execution
* Require at least one **affected component**
* Have their **severity auto-derived** from the highest-severity affected component
* Drive a **maintenance workflow** lifecycle (e.g. Scheduled → In Progress → Completed)
* Can optionally **start and stop automatically** at the scheduled times (see [Automatic start & stop](#automatic-start--stop))

The start and end times represent the **scheduled window only**. They are set at creation and are **not modified when you progress through the workflow**. You can post an "In Progress" timeline entry before the scheduled start if work begins early. That does not overwrite or shift the start time — your scheduled window stays exactly as set. If the actual window moved, edit Date & Time to match.

The timeline is a **narrative record** of what happened during the window. Timeline entry timestamps are independent from the window start/end times.

All times are stored and evaluated in **UTC**. See [Timezones](/docs/events/timezones) for how they appear to subscribers and on status dashboards.

### How times appear publicly
On **status dashboards** and in **subscriber notifications**, the platform shows the scheduled window using the stored start and end times. Display labels depend on the current workflow phase — the underlying times are **never changed** when you post timeline updates or when automation runs.

| Workflow phase                  | Start time label | End time label      |
| ------------------------------- | ---------------- | ------------------- |
| **Planned** (e.g. *Scheduled*)  | Expected start   | Expected completion |
| **Active** (e.g. *In Progress*) | Started          | Expected completion |
| **Final** (e.g. *Completed*)    | *(hidden)*       | *(hidden)*          |

* **Expected start** appears only while the event is still in the planned phase — before the window has begun.
* **Started** replaces that label once the event has moved into an active phase (manually or via automation). It still reflects the **scheduled** start time you set, not the timestamp of a timeline entry.
* **Expected completion** appears in planned and active phases. It is hidden in the final phase because the timeline already records completion.
* Both start and end are **required** when you create a maintenance event, so subscribers typically see both lines until the event is completed.

On the **Description** tab, you can optionally add **Impact Analysis** after the description. When set, it appears on status dashboard event cards and in full subscriber notifications (after the description, before affected components).

## Automatic start & stop
On the event **Date & Time** tab, you can enable **automatic start and stop** for a maintenance window. When enabled, the platform:

1. **Starts** the event at the scheduled **start time** — moves it from your **Planned** workflow phase to the next active phase (for example, *Scheduled* → *In Progress*).
2. **Stops** the event at the scheduled **end time** — moves it to your workflow's **final** phase (for example, *Completed*).

Each automatic transition adds a timeline entry. You can customize the timeline messages, or use the platform defaults.

Automation is **opt-in per event**. It is off by default. You can change start/end times or turn automation off before the window begins; if you move the event manually before a scheduled transition, the platform will not repeat that step.

### Workflow phases
Automatic start and stop uses your organization's maintenance workflow: the event begins in the **Planned** phase, moves to the first **active** phase at start time, and to the **Final** phase at end time. Workflow shape is enforced when you save workflows in Settings — see [Workflows — Automatic start and stop](/docs/events/workflows#automatic-start-and-stop).

### When transitions run (minute accuracy)
The platform checks for due maintenance transitions **about once per minute**. Scheduling uses **minute precision**: seconds on your start and end times are **saved and displayed**, but they do **not** delay when automation runs.

**Rule:** automation runs in the **minute that contains** your scheduled time — typically on the first check at or after the start of that minute. In practice, a transition may occur up to about **one minute** after the minute boundary.

#### Example window
| Field      | Value you set                         |
| ---------- | ------------------------------------- |
| Start time | `2026-05-01T02:00:45Z` (02:00:45 UTC) |
| End time   | `2026-05-01T04:30:22Z` (04:30:22 UTC) |

**When automation runs:**

| Transition | Scheduled minute | Runs around                                            |
| ---------- | ---------------- | ------------------------------------------------------ |
| Auto-start | `02:00` UTC      | First check at or after `02:00:00` — not at `02:00:45` |
| Auto-stop  | `04:30` UTC      | First check at or after `04:30:00` — not at `04:30:22` |

#### Auto-start — will it run?
Using start time `02:00:45` (treated as minute **`02:00`**):

| Platform check (UTC)  | Auto-start runs?                                                    |
| --------------------- | ------------------------------------------------------------------- |
| `01:59` (any seconds) | No — still before the `02:00` minute                                |
| `02:00` – `02:00:59`  | **Yes** — first eligible check in the `02:00` minute                |
| `02:01` or later      | **Yes** — if not already started (for example, after a brief delay) |

#### Auto-stop — will it run?
Using end time `04:30:22` (treated as minute **`04:30`**):

| Platform check (UTC)  | Auto-stop runs?                                      |
| --------------------- | ---------------------------------------------------- |
| `04:29` (any seconds) | No                                                   |
| `04:30` – `04:30:59`  | **Yes** — first eligible check in the `04:30` minute |
| `04:31` or later      | **Yes** — if not already completed                   |

Timeline entries created by automation still use your **full** stored start and end times (`02:00:45` and `04:30:22` in the example above) as their timestamps.

### Advance notification (optional)
You can optionally notify subscribers **before** the window starts — for example, 24 hours ahead. Configure this on the same Date & Time card when automation is enabled.

| Setting                       | Description                                                                                    |
| ----------------------------- | ---------------------------------------------------------------------------------------------- |
| **Send advance notification** | When on, subscribers receive a heads-up notification once, at `start time − lead time`.        |
| **Lead time**                 | How far ahead to send — a number plus **minutes**, **hours**, or **days** (default: 24 hours). |

Advance notifications follow the same rules as other event notifications: the event's **notifications** toggle must be on, and your organization's notification limits and subscriber settings apply. If the start time is already within the lead window when you enable advance notification, the advance notifications may send on the next check rather than in the past.

At start and end time, subscribers receive the usual event update notifications (if notifications are enabled) — in addition to any advance notice.

### Notifications and publishing
| Setting               | Effect on automation                                                                                                                                                                         |
| --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Notifications** on  | Subscribers receive notifications for advance notice (if enabled), auto-start, and auto-stop.                                                                                                |
| **Notifications** off | Transitions still occur; no subscriber notifications.                                                                                                                                        |
| **Publish** on        | Automation runs at the scheduled times (minute precision). Status dashboards reflect automated transitions.                                                                                  |
| **Publish** off       | Automation is **configured but does not run** — no auto-start, auto-stop, or advance notifications. Unpublishing **halts** all pending automation. Draft events do not appear on dashboards. |

### Manual changes
| You do this                                   | Platform behavior                                                                                                                         |
| --------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| Post **In Progress** before start time        | Auto-start is skipped; auto-stop still runs at end time if enabled.                                                                       |
| Post **Completed** before end time            | Auto-stop is skipped.                                                                                                                     |
| Change start or end time                      | Remaining automated steps reschedule to the new times. Advance notification does **not** send again if it already went out.               |
| Turn automation off                           | No further automatic transitions. Past automation steps remain visible in the event's automation history.                                 |
| Turn automation back on                       | Automation resumes from the current workflow phase. Steps already completed (advance notice, auto-start, auto-stop) are **not** repeated. |
| Edit workflow phases after creating the event | Existing events use the workflow configuration when each transition runs.                                                                 |

### Moving back to the planned phase
You may move a maintenance event back to your **Planned** phase (for example, *Scheduled*) at any time — for instance, if a window was started early and you need to reset the narrative. That is your choice.

When you do, and automation is still enabled:

* **Auto-start** can run again at the scheduled start time (or on the next minute check if that time has already passed).
* **Auto-stop** will **not** run while the event is in the planned phase — completion only happens after the event has moved into an active phase (automatically or manually).
* **Advance notification** is **not** sent again if it already went out for this event.

The Date & Time tab shows which automation steps have already occurred. Moving back to planned clears the start and complete markers from that history, but keeps advance notification if one was sent.

### Disabling and re-enabling automation
Turning automation **off** stops all pending transitions immediately. The event stays at its current workflow phase. Automation history on the event is kept for your records.

Turning automation **back on** does not reset that history. The platform will not repeat steps that already completed — for example, it will not send a second advance notification or auto-start an event that already moved to an active phase. If you need automation to run again from planned, move the event back to the **Planned** phase first (see above).

### Reliability
Automatic transitions are checked about once per minute. If a transition is interrupted (for example, by a brief platform issue), the platform will retry on a later check rather than leaving the event stuck between steps. You do not need to take action for this self-healing behavior.