Maintenance windows and deploy mutes

A maintenance window is a period during which CompleteStatus suppresses alert notifications for some or all monitors in a project. Checks keep running, results keep being recorded, and incidents still open and resolve as usual — you just don't get paged about downtime you caused on purpose. The time inside a window is also left out of uptime %, so planned work doesn't count against your uptime or SLA figures.

Maintenance windows are managed per project at /settings/maintenance.

Quick mute: "Deploying now"

For unplanned, short work — a deploy, a config change, a restart — you don't need to fill in a form:

1. Open /settings/maintenance and make sure the right project is selected.
2. Click Mute for 30 min or Mute for 60 min.

This immediately creates an active window covering every monitor in the project, with the reason "Deploying now". It appears in the Active list, where you can end it early once the deploy is done.

Scheduling a maintenance window

For planned work, schedule a window in advance:

1. On /settings/maintenance, open the scheduling form.
2. Fill in:
   • Starts at — date and time the mute begins (defaults to now).
   • Ends at — when alerting resumes. Must be after the start.
   • Open-ended — tick this instead of an end time to mute until you manually end the window. Use with care.
   • Monitors — pick the monitors the window covers. Selecting none covers all monitors in the project, including monitors you add later.
   • Reason — optional note (up to 255 characters) shown in the window list, e.g. "Database migration".
3. Save. The window shows under Upcoming until its start time, then moves to Active, then to Past.

Managing existing windows:

• End now — stamps the end time to the current moment, immediately restoring alerting.
• Delete — removes the window entirely (works on upcoming, active or past windows).

Note: Windows are one-off. There is no recurrence option — for a weekly maintenance slot you need to schedule each window (or create them via your deploy tooling).

What a maintenance window does — and doesn't do

During an active window that covers a monitor:

• Alert fan-out is fully suppressed. When an incident opens or resolves on a covered monitor, no notifications go to any channel — email, chat (Slack, Teams, Discord, Telegram, Google Chat, Mattermost, Rocket.Chat, Zulip, Webex, Matrix), push (ntfy, Pushover, Gotify), webhooks, pagers (PagerDuty, Opsgenie) or ticketing (GitHub, GitLab, Jira, Linear) — and no automation hooks fire either. The suppression is logged, and it applies to the whole event, not per channel.
• Checks keep running. Check results and response times are recorded as usual.
• The window's time is left out of uptime %. Time inside a maintenance window (including quick mutes and a monitor's Mute) counts as neither up nor down, and downtime inside it does not count against uptime anywhere it is shown: SLA reports, status pages, badges, LiveStatus walls, the dashboard, the REST API and MCP. A window only excludes time from the moment it was created, so scheduling one in the past never erases downtime that was already recorded. An open-ended window keeps excluding time until someone ends it.
• Incidents are still recorded. If the service goes down mid-window, the incident opens, builds its timeline, and auto-resolves on recovery exactly as described in /docs/incidents-and-escalation — you can review it afterwards at /incidents.

What it does not do:

• It does not change monitor status. Monitors covered by a window still show Up or Down on dashboards and status pages, and a status page's overall banner is worked out exactly as it is outside a window. The one place a window shows is a LiveStatus wall: there an Up or Pending monitor inside an active window shows as Maintenance, with the time the window ends if it has one. A monitor that goes down during the window still shows as down on the wall too.
• It does not hide a live outage from public status pages. A monitor that goes down during maintenance shows as down while it is down, and the incident appears in the page's incident history. What changes is the uptime history: the window's time is left out of the uptime %, and a day whose only downtime fell inside the window shows as Maintenance (blue) in the uptime bars, not as an outage. To tell visitors about planned work ahead of time, publish an announcement on the page. Windows you schedule in Settings → Maintenance also appear in the page's RSS feed and iCal calendar.
• It does not stop checks. To stop checking entirely, pause the monitor from its page instead — but note a paused monitor records nothing at all while paused.

Warning: An open-ended window silences alerts, and leaves time out of uptime %, indefinitely until someone presses End now. If your alerts seem to have gone quiet, check the Active list on /settings/maintenance first.

Moving a monitor to another project

Maintenance windows belong to a project. You can move a monitor with Move to project on the Monitors list, the project field on its edit form, or the REST API. After a move, different windows cover it. What happened before the move does not change:

• Time before the move keeps its old maintenance. It keeps the windows of the project the monitor was in at the time. Planned work in the old project doesn't become downtime after the move. The new project's earlier windows don't hide outages from before the move either. Uptime %, the daily bars on status pages and walls, and SLA reports read the same before and after the move.
• From the move on, the new project's windows apply. The old project's windows stop covering the monitor, including one that is running at the time of the move.
• A monitor's own Mute moves with it. It keeps muting until its original end time. Scheduled windows, quick mutes and API windows stay with their project, even if they list the monitor.

Moves made before September 2026 weren't recorded. For a monitor moved before then, all of its earlier history counts as time in the project it was in at that point.

Suppression is evaluated at send time

The mute check happens at the moment an alert would be sent, not when the incident opens. Two practical consequences:

1. If a monitor goes down before the window starts and recovers during it, you get the down alert but the up (recovery) alert is suppressed.
2. If it goes down during the window and recovers after the window ends, the down alert is suppressed but the recovery alert is delivered.

Plan window boundaries with a little margin around the actual work to avoid a stray page at the edges.

Maintenance windows vs. other muting tools

Availability

Maintenance windows are available on every plan, including Free, with no limit on the number of windows.

Related guides

• /docs/incidents-and-escalation — the incident lifecycle windows interact with.
• /docs/alert-channels — channels, rules and cooldowns.

Further reading: Maintenance windows done right on the blog — planning, communicating and running planned downtime.