Maintenance
A planned maintenance window.
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)
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 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:
- 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).
- 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.
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.