How to schedule maintenance windows so uptime alerts stay quiet during deploys

To stop uptime alerts during a deploy or planned maintenance, schedule a maintenance window in HyperMonitors: Settings → Maintenance → New maintenance window, give it a name, pick the monitors it covers (or apply it to all of them), set a start and an end, and save. While the window is active, the covered monitors are still checked on their normal schedule and every result is recorded, but no incident is opened and no alert goes out. You can repeat a window weekly, it shows up as planned maintenance on your status page, and you can create one from your deploy pipeline with a single API call. Maintenance windows are available on every plan, including Free.

Why not just pause the monitor?

Pausing works, but it costs you the data. A paused monitor has a hole in its history for exactly the period you'd most like to look at later: did the rolling deploy really keep the site up, how long did the database actually take to come back, did the new version respond slower than the old one? A maintenance window keeps all of that. The engine runs every check as usual and stores the result, it only skips the part that wakes you up. And unlike pausing, you don't have to remember to turn it back on at two in the morning, because the window ends on its own.

Schedule a one-off window

Open Settings and switch to the Maintenance tab. Click New maintenance window and fill in:

• Name: what the window is for, up to 100 characters. “API deploy 1.14” beats “maintenance”, because the name is what your status page visitors will read.
• Scope: turn on Apply to all monitors, or leave it off and tick the monitors the work affects. One of the two is required, the form won't save a specific selection with nothing in it.
• Start and End: the end has to be after the start. Times are shown in your organization's timezone, so what you type is what you mean.
• Note (optional): up to 500 characters that appear on the status page next to the window. “Database migration, logins may fail for a few minutes” is the kind of thing that stops support tickets.

Save with Schedule window. In the list, a window that is currently running is marked Active now, and you can delete one at any time. If the deploy overruns, schedule a follow-up window (or extend the existing one through the API) rather than letting alerts fire halfway through the work.

Keep it tight

A window is a blind spot by design, so make it as short as the work really needs. Fifteen minutes around a deploy is usually plenty. A generous four-hour window “to be safe” means a genuine outage at the end of it would go unalerted. And scope it to the monitors that are actually affected: a database migration doesn't justify silencing the monitor on your marketing site.

Repeat it every week

For recurring work, a nightly backup that takes the database read-only or a Sunday patch slot, turn on Repeat weekly. You then pick the weekdays, a start time and a duration in minutes (anything from 1 up to 1440, a full day). The start and end dates stop being the window itself and become the period in which the pattern repeats: within that period, alerts pause on the chosen weekdays from the start time for the given duration. Set the end a year out if the slot is permanent, or to the last planned run if it isn't.

The start time is interpreted in your organization's timezone and follows daylight saving, so a window saved as 02:00 fires at 02:00 local in summer and winter alike. That matters if your cron job runs on local time too, which it almost always does. If you haven't set the organization timezone yet, do that first, under Settings.

What your customers see

If you have a public status page, windows that cover its monitors appear on it automatically. A future one is listed as Scheduled maintenance, a running one as Maintenance in progress, each with the name, the time range and your note. That turns “is it down?” into “ah, they said this would happen” before anyone writes in. Status pages on plans that include email subscribers also email those subscribers about maintenance, so your customers hear about the Sunday patch slot the same way they hear about an incident.

Because checks keep running, your uptime history shows what really happened during the window, not a gap. If the deploy did cause a minute of 503s, that minute is in the data. That is exactly what you want when you reconcile planned downtime against an SLA, where the question is never “did the monitor notice” but “what did we promise, and did we exclude announced maintenance from it”.

Create the window from your deploy pipeline

The step most teams skip is the one that makes this stick: have the pipeline create the window instead of a human. Right before the deploy job, one request with a write-capable API key opens a short window on the monitors that job touches:

# HYPERMONITORS_API_KEY = write-capable key from Settings → API keys
curl -fsS https://api.hypermonitors.com/v1/maintenance-windows \
  -H "Authorization: Bearer ${HYPERMONITORS_API_KEY}" \
  -H 'content-type: application/json' \
  -d '{
    "name": "API deploy '"$GIT_SHA"'",
    "monitorIds": ["MONITOR_ID"],
    "startsAt": "'"$(date -u +%Y-%m-%dT%H:%M:%SZ)"'",
    "endsAt": "'"$(date -u -d '+15 minutes' +%Y-%m-%dT%H:%M:%SZ)"'",
    "note": "Rolling deploy, a few requests may fail briefly"
  }'

An empty monitorIds array means the whole organization. For a weekly slot, add a recurrence object with daysOfWeek (0 is Sunday, 6 is Saturday), a startTime like 02:00 and durationMinutes; the outer startsAt and endsAt then bound the period it repeats in. The same endpoint lists existing windows with GET, and PATCH or DELETE on a window's id updates or removes it, so a pipeline that finishes early can shorten the window instead of leaving it open. The full field list is in the API docs under Maintenance windows.