Maintenance Windows

Planned downtime that doesn't page you, doesn't open an incident, and doesn't dent your uptime numbers — while the checks keep running.

What is a maintenance window?

A maintenance window is a period you declare in advance (or start on the spot) during which a set of monitors keeps being checked, but stops alerting.

Example: "Every Tuesday at 02:00 Europe/Berlin we deploy for about an hour. Don't wake anyone up, and don't count that hour against our uptime."

Three things happen while a window is in effect:

1. Checks still run. Every result is still recorded, so you keep full visibility of what actually happened during the window.
2. Alerts stop. No Down alert, no incident opened, no push notification, no bell entry — for the monitors in that window only.
3. The numbers ignore it. Checks that ran inside the window are left out of your uptime percentage and average response time entirely — not counted as up, and not counted as down.

The monitor shows as Maintenance rather than Down for the duration, in the monitor list, on the detail page, and on any public status page it appears on.

When to use it

• Deploys and releases. The classic case — a recurring window over your release slot so a 90-second restart never pages the on-call.
• Database migrations, host moves, DNS cutovers. Anything where you expect to fail checks for a known period.
• Third-party maintenance. Your provider announced a window; declare the same one so their downtime doesn't burn your error budget.
• A monitor you're actively working on. Start maintenance for an hour rather than pausing the monitor — you keep the check history, you just stop the noise.

When not to use it:

• To silence a noisy monitor. That's what snooze is for. Snooze stops paging you for a while but still records everything in the activity feed; maintenance is a statement about the monitor and applies to everyone who would be notified, teammates included.
• To stop checking altogether. That's pause. A paused monitor produces no results at all; a monitor in maintenance keeps producing them.
• To hide an outage that's already happening. It won't work, by design — see the next section.

What a window silences — and what still gets through

This is the part worth reading carefully, because "suppress alerts" is not the same as "go silent".

Silenced for the monitors in the window

Deliberately not silenced

An incident that was already open before the window started keeps paging. If your API went down at 01:40 and you declare a window at 02:00, that outage is a real one you were already being told about — declaring maintenance afterwards is not consent to go quiet on it. Enori compares the two timestamps: incident opened before the window began → alerts continue.

Notices that the monitoring itself is broken. If a check can't be executed at all — after every retry — you're told, window or no window. A customer sitting inside a maintenance window who is never told their monitoring stopped working would believe they're covered when they aren't. These notices are one-shot, so suppressing one wouldn't delay it, it would destroy it.

Status-page subscriber notifications. A status page exists to show planned maintenance, not to go quiet during it. So the window appears on the page, and subscribers to your status pages are notified when it starts and when it ends — plus beforehand, if you set an advance notice on the window. See Where maintenance shows up.

Notices that the monitor's setup changed. A monitor being shared with a team, unshared, or edited is news about your configuration, not about its health — so a teammate is still told. A window says "this outage is planned"; it doesn't say "don't tell my team I just handed them this monitor." These arrive once per action, not once per check, so they can't become noise.

Corrections to something already on your screen. If your phone's lock screen is showing an open incident, it keeps being corrected as that incident is acknowledged or resolved — window or no window. Withholding a notification hides information; withholding a correction publishes a false one, and leaves the lock screen frozen on "Down" for something that has already recovered.

Anything not tied to a monitor. Billing email, team invitations, account notices — a maintenance window says nothing about those, so they're unaffected.

What it does to your uptime numbers

Uptime % and average response time exclude maintenance completely. A check that ran inside a window is removed from both the numerator and the denominator — it's neither a success nor a failure. This applies to every kind of window (one-time, daily, weekly, monthly, quick and bulk), because each check result is stamped as "in maintenance" at the moment it runs.

This matches how the rest of the industry reports uptime, and it means a planned window can never make your reported availability look worse than reality.

On the 90-day uptime strip, a day where at least half the checks ran inside a window is drawn as a maintenance day rather than an up or down day.

SLOs have their own Exclude maintenance setting, which is on by default. With it on, checks that ran inside a window don't burn your availability error budget. See the SLO guide for the full picture, including the paired Exclude paused setting.

The three ways to declare maintenance

This is the single most confusable part of the feature, so here it is up front. All three suppress alerts identically — they differ in when, how long they live, and whether they count against your plan.

A fourth badge, MCP, marks a window created through the MCP server. It behaves like a scheduled window — it stays in your list until you delete it, and it counts against your plan limit.

Rule of thumb: if it happens on a rhythm, schedule it. If it's happening right now and you just need quiet, use Quick or Bulk — those are deliberately free and unmetered, because an emergency pause behind a paywall would be an anti-feature.

Creating a scheduled window

Go to Maintenance in the sidebar (/dashboard/maintenance) and click Create Window. Make sure the Scheduled tab is selected at the top of the dialog (the other tab, Start Now, is covered below).

Screenshot: the Create Maintenance Window dialog on the Scheduled tab, with the Weekly schedule type selected so the day picker, start time, duration and time zone are all visible.

1. Name — required

Up to 100 characters. This name is what you'll see in the list, what your status-page visitors see under "Scheduled Maintenance", and what shows on the monitor's Maintenance card while the window is running. Make it descriptive: "Weekly deploy window", not "mw1".

2. Schedule type — required

Four options. The rest of the form changes depending on which you pick.

3. Timing

For One-Time: pick a Start and an End. The end must be after the start, and it must not already be in the past — a window that already finished would never do anything, so Enori rejects it rather than letting you create something inert.

For Daily / Weekly / Monthly: pick the Start Time (hours and minutes) and a Duration from the preset list: 15 min · 30 min · 1 hour · 2 hours · 4 hours · 8 hours.

• Weekly adds a day picker, Sunday through Saturday.
• Monthly adds a day-of-month picker limited to 1–28. That's deliberate: a window set for the 30th would silently skip February, so the picker only offers days that exist in every month.

4. Repeat until — optional (recurring windows only)

Leave it empty and the window repeats indefinitely. Set a date and no occurrence will begin on or after it — so the last run is the one before that date, and an occurrence already running when the date arrives still finishes normally.

Enori rejects a terminator that would make the window pointless: a date already in the past, or one that falls before the schedule's next occurrence ("every Sunday, until Tuesday" has no Sunday left to run). To stop a recurring window sooner than planned, edit this date rather than deleting the window — you keep the record.

5. Time zone — required

A searchable list of every IANA time zone, shown with its current UTC offset ("(UTC+02:00) Europe/Sofia").

Check this field anyway. It pre-fills with your browser's own time zone, falling back to UTC only if your browser can't report one. That's almost always what you want — but a recurring window set for 02:00 in the wrong zone will fire hours away from your deploy, and the zone is the one field a wrong value doesn't announce itself in.

Recurring windows honour daylight saving in the zone you pick — a 02:00 window stays at 02:00 local across the spring and autumn changes.

6. Notify subscribers in advance — optional

Notify subscribers in advance emails the subscribers of any status page carrying these monitors before the window starts — 15 minutes · 1 hour · 6 hours · 1 day · 3 days · 7 days of lead time. It's off by default, deliberately: a lead time we'd chosen for you would turn a daily window into a daily mail to every subscriber, sent because we shipped rather than because you asked.

The notice is sent once per occurrence, so a weekly window announces itself once a week, not once per check. It's independent of the start and end emails, which always go out.

7. Affected monitors — required

Two ways to say who a window covers, chosen with the toggle at the top of this field.

Specific monitors (default) — tick the ones you want. Select all / Deselect all shortcuts sit above the list, and the count of selected monitors is shown on the right. The membership is frozen: exactly these monitors, until you edit the window.

By tag — pick one or more tag chips instead, and membership follows them. A monitor tagged later joins the window on its own; one that loses the tag leaves it. Several tags match any of them. The chips offer the tags your monitors already carry, plus any this window already follows, and the dialog shows how many monitors those tags cover right now and names the first few. A window whose tags nothing currently carries is legal and stays editable — it simply covers nobody until something is tagged again.

Tag scope is the right choice when the set is the thing you maintain ("everything tagged checkout") rather than a fixed list. Note that + Add to existing window on a monitor's Maintenance card can't touch a tag-scoped window — adding the tag is how a monitor joins one.

Click Create Window. The window takes effect on schedule; you don't have to do anything else.

Starting maintenance right now

Three entry points, all instant, none of which count against your plan limit.

From a single monitor

Open the monitor, find the Maintenance card in the right-hand rail, and click Start maintenance now. (The same thing is available without leaving the monitors list — the row's ⋯ menu has Start Maintenance / End Maintenance.) Choose a Duration (15 min · 30 min · 1 hour · 2 hours · 4 hours · 8 hours · 24 hours, default 1 hour) and optionally a Reason (up to 500 characters — "Deploying v2.5"). Click Start Maintenance.

The reason is carried into the window's name, so it's what you'll see on the card and in the maintenance list while it's running — as "Quick maintenance: Deploying v2.5". Leave it blank and the monitor's own name is used instead. (A bulk window started for several monitors uses the reason as-is, or "Bulk maintenance (N monitors)".)

To stop early, open the same card — while a window is running it shows Active until … and an Edit window button — and choose End Maintenance in the dialog it opens. The window deletes itself. (The row's ⋯ menu on the monitors list offers End Maintenance directly.)

If that monitor is covered by a window that also covers others — a bulk window, or a scheduled one — ending it here ends it for all of them. A teammate who doesn't own the window can only end one that covers nothing but the monitor they have access to; otherwise Enori refuses and says so.

Screenshot: a monitor detail page with the Maintenance rail card showing "Active until …" plus the reason.

For several monitors at once

Select the monitors on the monitors list and choose Start Maintenance, or go to Maintenance → Create Window → the Start Now tab. Pick a duration, optionally a reason, tick the monitors, and click Start Maintenance. One window covers all of them.

Adding a monitor to a window that already exists

On the monitor's Maintenance card, + Add to existing window lists your enabled windows that don't already include this monitor — except windows that follow tags, which this control can't change. Pick one and the monitor is added; no need to rebuild the schedule. If the window is running right now, the monitor is covered immediately.

The button only appears while the monitor is not currently in maintenance — during a window the card shows Edit window instead.

If the picker says "No eligible windows" and you know you have some, they follow tags. The dialog names those tags — add one of them to this monitor and it joins the window on its own.

Managing your windows

The Maintenance page lists every window you own as a card.

Filter tabs — the list opens on Active. If you've just created a window for next Tuesday and the page looks empty, switch to Scheduled (or All).

Each card shows the window's name, a source badge (Scheduled / Quick / Bulk / MCP), a status badge (Active / Scheduled / Disabled), a plain-English summary of the schedule, how many monitors it covers, when it ends if it's running, and its time zone.

Actions on each card:

• Edit — change anything: name, schedule type, timing, duration, time zone, monitors. Changes take effect immediately. If you edit a window while it's running, an unrelated edit (a rename, adding a monitor) won't cut the current window short — but moving or shrinking the schedule will, because that's you saying the work isn't happening now after all.
• Start Now — begin a scheduled window immediately instead of waiting.
• End Now — end a running window early. A one-time window is marked completed; a recurring one rolls straight on to its next occurrence, unaffected.
• Delete — removes the window permanently. Any monitors it covered start alerting again straight away.

A disabled recurring window is offered neither Start Now nor End Now: starting it would silently re-arm every future occurrence. Re-enable it first (PUT /api/maintenance/{id} with isEnabled: true, or the update_maintenance_window MCP tool).

The list updates live — a window starting or ending, or a change made from another device or the API, appears without a refresh.

How many windows you can have

Only standing windows count — the ones you schedule from the UI, or create through the API or MCP server (badged Scheduled or MCP). Quick and bulk maintenance are unlimited and never metered.

Hitting the limit returns a clear "plan limit reached" message with an upgrade prompt. One window can cover as many monitors as you like, so a single "Weekly deploy" window across 40 monitors costs you one of your two on Base.

Where maintenance shows up

• Monitor list and detail page — the monitor's status reads Maintenance, and a banner on the detail page shows when alerts resume and the reason.
• The Maintenance rail card on the monitor detail page — "Active until …" plus the window's name while it's running.
• Timeline — maintenance is one of the seven event families on the calendar, so you can see windows alongside incidents and config changes.
• Upcoming (dashboard panel) — scheduled maintenance appears alongside SSL and domain expiries, so you can spot conflicts before they happen. Recurring windows show across the panel's whole horizon; a one-time window appears once it's within seven days.
• Public status pages — a monitor in maintenance renders as Maintenance rather than Down, a Scheduled Maintenance section lists upcoming windows (including the next occurrence of recurring ones) so visitors see planned downtime in advance, and a Past Maintenance section lists windows that finished within the page's history period. Both history sections are governed by the page's Show incident history setting. Status-page subscribers are emailed when a window starts and when it ends — and beforehand if you set an advance notice.
• Audit log — creating, updating, deleting, starting and ending windows is recorded — from the UI, the API and the MCP server alike — along with quick and bulk maintenance starts.

Doing it from the API or an AI client

Maintenance windows are fully scriptable, which is the natural home for "my deploy pipeline declares its own window".

REST — /api/maintenance: list, get, create, update, delete, plus POST /api/maintenance/{id}/start-now, POST /api/maintenance/{id}/end-now, and POST /api/maintenance/quick for an instant multi-monitor window. Per-monitor instant maintenance lives on the monitor itself: POST and DELETE /api/monitors/{id}/maintenance. API keys need the maintenance:read scope to read and maintenance:write to change anything. See the API reference.

MCP — seven tools are available to any MCP client: list_maintenance_windows, get_maintenance_window, create_maintenance_window, update_maintenance_window, delete_maintenance_window, start_maintenance_now and end_maintenance_now. So you can say "put the checkout monitors in maintenance for the next hour" from Claude, and "that's done, end it" when the deploy finishes early. create and update accept the same recurrence terminator, advance notice and tag scope as the UI. Windows created this way are badged MCP in your list and count against your plan limit.

Starting maintenance is rate-limited to 10 per hour per account, and that budget is shared across the three UI and REST ways of doing it — scheduled windows, quick maintenance on a single monitor, and bulk maintenance. The MCP tools run on their own separate rate limit and do not draw on it. One bulk window covering forty monitors costs one, which is the reason to reach for it during a fleet deploy rather than starting maintenance monitor by monitor.

Reference: limits and bounds

FAQ

Does the monitor stop being checked?

No. Checks run on their normal schedule throughout the window, and every result is recorded. That's the whole point — you can look back afterwards and see exactly what happened during the deploy. What changes is that failures don't alert, don't open incidents, and don't count toward uptime.

What's the difference between maintenance, snooze and pause?

Snooze is about your attention — it stops paging you but keeps a full record in the app, because muting a noisy monitor and then finding its history missing would be a worse surprise than the noise. Maintenance is about the monitor, so it applies to your teammates too, and it does hide the events from the bell.

My API went down 20 minutes before the window started. Will I still be paged?

Yes. An incident that opened before the window began keeps alerting — a window declared afterwards isn't treated as consent to go quiet about a problem you were already being told about. A new failure that starts inside the window is suppressed normally.

Will my status-page visitors see the window?

Yes, and that's intentional. A monitor in maintenance shows as Maintenance rather than Down, upcoming windows are listed in a Scheduled Maintenance section, finished ones in a Past Maintenance section, and status-page subscribers are emailed when the window starts and ends — plus beforehand if you set an advance notice. Maintenance is the one case where a status page should get louder, not quieter.

What happens to a recurring window after each occurrence?

It rolls forward automatically to its next occurrence. You don't have to touch it. Ending one occurrence early doesn't cancel the next one. If you set a Repeat until date, it rolls forward until the last occurrence before that date, then stops on its own.

Does a one-time window disappear after it runs?

It stays in your list, marked Disabled, under the Completed filter — so you keep the record. Delete it when you no longer need it. Quick and bulk windows behave differently: they delete themselves as soon as they end.

Can two windows overlap on the same monitor?

Yes. The monitor is in maintenance for as long as any covering window is running, so ending one of two overlapping windows won't accidentally un-suppress the monitor.

Does daylight saving move my window?

No. Recurring windows are evaluated in the time zone you picked, so a 02:00 window stays at 02:00 local time across both changeovers.

Can teammates I've shared a monitor with still get paged during my window?

No. Maintenance is declared by the monitor's owner about the monitor, so it applies to everyone who would be notified about it — including escalation targets.

Troubleshooting

The window ran but I still got alerts

Check, in this order:

1. Is the monitor actually in the window? Open the window with Edit. If Affected Monitors is set to Specific monitors, confirm this one is ticked. If it follows tags, confirm the monitor carries one of them — the dialog shows the current match count. This is by far the most common cause.
2. Is the window enabled? A card with a grey Disabled badge won't suppress anything. Finished one-time windows are automatically disabled.
3. Is the time zone right? A window at 02:00 UTC when you meant 02:00 Europe/Berlin runs an hour or two off. The card shows the zone under the schedule summary.
4. Was the incident already open? If the outage started before the window did, alerts continue on purpose.
5. Was it a "your monitoring is broken" notice? Those always get through.

The Maintenance page looks empty even though I just created a window

The list opens on the Active filter. A window scheduled for the future isn't active yet — switch to Scheduled or All.

My monthly window never fires on the 29th, 30th or 31st

The day picker stops at 28 on purpose, so a monthly window fires in every month including February. For month-end work, use the 28th, or create a one-time window per month.

I can't create a new window — "plan limit reached"

You've used all your scheduled windows (2 on Base, 10 on Pro). Options: delete a window you no longer need, cover more monitors with one window instead of several, use quick/bulk maintenance (unlimited) for one-off events, or upgrade.

A monitor shows "Maintenance" but I never scheduled anything

Someone — or something — started maintenance outside your scheduled windows. Check the Maintenance page on the Active filter: the card will be badged Quick (started on one monitor), Bulk (started on several at once) or MCP (created by an AI client through the MCP server), and its name carries the reason that was entered. The audit log records who started it and when. End it early with End Now, or from the monitor's Maintenance card.

Adding a monitor to a window that's already running — does it take effect immediately?

Yes. Coverage is worked out from the window's monitor list every time a check runs, so a monitor added mid-window is covered on its very next check.

Related documentation

• Service Level Objectives — the Exclude maintenance setting on an SLO, and how error budgets treat planned downtime
• Timeline — see maintenance windows alongside incidents, alerts and config changes on one calendar
• Audit log — who created, changed or started which window
• API reference — /api/maintenance endpoints and scopes
• MCP server — driving maintenance from Claude or another MCP client

Draft — last updated 2026-08-21. Feedback or corrections: support@enori.io