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 subscribers to your status pages are notified when a window starts and when it ends, and the window appears on the page — see Where maintenance shows up.

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 that was more than half maintenance 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.

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. 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. It defaults to your browser's time zone only when that's one of the common zones; otherwise it falls back to UTC. A recurring window set for 02:00 in the wrong zone will fire hours away from your deploy.

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.

5. Affected monitors — required

Pick at least one. Select all / Deselect all shortcuts sit above the list, and the count of selected monitors is shown on the right. A window only ever affects the monitors listed here — everything else keeps alerting normally.

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 becomes the window's name, so it's what you'll see on the card and in the maintenance list while it's running.

To stop early, open the same card and choose End Maintenance. The window deletes itself.

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. 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.

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), 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.

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 scheduled windows count. Quick and bulk maintenance are unlimited.

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.
• Public status pages — a monitor in maintenance renders as Maintenance rather than Down, and a Scheduled Maintenance section lists upcoming windows (including the next occurrence of recurring ones) so visitors see planned downtime in advance. Status-page subscribers are emailed when a window starts and when it ends.
• Audit log — creating, updating and deleting windows is recorded, along with 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 — list_maintenance_windows, create_maintenance_window and start_maintenance_now are available to any MCP client, so you can say "put the checkout monitors in maintenance for the next hour" from Claude.

Creating windows is rate-limited to 10 per hour per account. Instant maintenance from the UI is not affected in normal use.

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, and status-page subscribers are emailed when the window starts and ends. 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.

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 and confirm it's ticked in Affected Monitors. 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 quick or bulk maintenance. Check the Maintenance page on the Active filter: the card will be badged Quick or Bulk, 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-07-29. Feedback or corrections: support@enori.io