A maintenance window announces planned downtime ahead of time. Where an incident is a record of an unexpected problem, a maintenance window is a scheduled period — a deploy, a database migration, a host reboot — that you expect to affect a monitored service, communicated in advance so it isn't mistaken for an outage.

Each maintenance window is scheduled against a monitor and has a fixed start and end time, an optional description, and optional recurrence.

When to use a maintenance window

Use a maintenance window (instead of an incident) when the downtime is:

Planned — you know about it before it happens.
Time-boxed — it has a defined start and end.
Expected — the dip in availability is intentional, not a failure.

For an unplanned problem you're reacting to, open an incident instead.

What a maintenance window contains

Field	Description
Title	Short summary of the planned work (required).
Description	Longer explanation of what's happening and the expected impact (optional).
Monitor	The monitor the window applies to (optional — leave empty for an account-wide window).
Start time	When the maintenance begins (required).
End time	When the maintenance is expected to finish (required).
Recurring	Whether the window repeats.
Recurrence rule	The repeat pattern, when the window is recurring (e.g. a weekly cadence).

The window's time range is what tells StatusRadar — and your users — to expect reduced availability between start_time and end_time.

Scheduling a window

When you schedule a maintenance window:

Give it a clear title describing the work.
Optionally select the monitor it affects. Tie it to the specific service going down so the announcement is targeted; leave it unset for broader, account-wide maintenance.
Add a description so readers know the expected impact and any workaround.
Set the start time and end time that bracket the work.
If the work repeats (for example a regular weekly reboot), mark it recurring and define the recurrence rule.

Schedule windows ahead of the work so the announcement is visible before downtime begins.

Recurring maintenance

For repeating operations — a nightly job, a weekly patch window — mark the window recurring and set a recurrence rule that describes the cadence. A single recurring window covers every occurrence, so you don't have to re-create it each time. Use one-off (non-recurring) windows for unique, planned events like a major migration.

Maintenance vs. incidents

	Maintenance window	Incident
Nature	Planned, expected	Unexpected problem
Timing	Scheduled in advance, fixed start/end	Opens when the problem starts
Lifecycle	Begins and ends on its schedule	Moves through `investigating → identified → monitoring → resolved`
Created by	You, ahead of time	Automatically (monitor down / anomaly) or manually
Recurrence	Can repeat on a rule	One per occurrence

Tips

Schedule early. Add the window before the work so the announcement is up before downtime begins.
Be specific about impact. Say which service is affected and for how long.
Match the time range to reality. Keep start_time/end_time aligned with the actual work so expectations are accurate.
Mute related anomaly alerts. Planned downtime can otherwise trigger anomaly detection. See Anomaly detection for reducing false positives around scheduled maintenance and deployments.

Next Steps

Incidents overview — how incidents differ from maintenance
Managing incidents — handle unplanned problems
Status pages — where your users see status and announcements
Anomaly detection — avoid false alarms during planned work

On this page

When to use a maintenance window
What a maintenance window contains
Scheduling a window
Recurring maintenance
Maintenance vs. incidents
Tips
Next Steps