Does a maintenance window count as downtime in my uptime percentage?

Not in PingRobot. Monitors covered by an active window are not checked at all, so no result is recorded. Uptime is calculated from recorded checks, which means the window counts neither as up nor as down, and the same applies to SLA figures on status pages.

Should a maintenance window cover all monitors?

Only if the work really affects everything. Covering all monitors is convenient, but it also hides unrelated outages that start during the window. Include the services the work touches and the ones that depend on them, and leave the rest checking.

What happens if maintenance runs longer than the window?

Checks resume when the window ends. If the service is still down, the next check records a failure and alerts as usual, subject to any alert delay. Extend the window before it ends if you know the work will overrun, or accept the alert as an accurate signal that it did.

Do I still need a status page notice if I have a maintenance window?

Yes. The window only controls your monitoring. Customers learn about planned work from a maintenance announcement on the status page, posted in advance and updated when the work starts and finishes.

Scheduled Maintenance Without False Alerts: Maintenance Windows Done Right

To avoid false alerts during planned work, create a maintenance window: a period during which your uptime monitor skips checks for the monitors you choose, so a scheduled restart or migration does not page anyone. Use a one-off window for a single job, such as a database upgrade on Saturday night, and a recurring daily or weekly window for routine work, such as Sunday patching. Set the window's time zone explicitly, include only the monitors the work affects, and post a maintenance notice on your status page before the work begins. Done that way, the window protects your team from noise and your customers from surprises.

Why maintenance creates false alerts

An uptime monitor cannot tell planned downtime from an outage. A web server restarting for a kernel update returns connection errors exactly like one that crashed. Without a window, you get one of three bad outcomes: someone is woken for work they scheduled, someone silences alerts by hand and forgets to turn them back on, or the team learns to ignore alerts that arrive during maintenance hours. That last one is a direct route to alert fatigue, and it is the most dangerous, because real outages also happen during maintenance hours.

A window solves this by being specific: these monitors, this time, nothing else.

One-off vs recurring windows

One-off windows have a start and end time and are used once. They fit:

A planned migration or upgrade on a specific date.
A deploy that restarts services.
A provider's announced maintenance that you cannot avoid.

Recurring windows repeat daily or weekly at a local time. They fit:

Nightly backups that lock a database for a few minutes.
Weekly OS patching or container image refreshes.
A scheduled reindex or cache rebuild.

Limits vary between tools. In the API used later in this article, a one-off window can last up to seven days. A daily or weekly window has a start time and a length between 5 minutes and 24 hours, and may run past midnight; a weekly window is tied to the day it starts on. One-off windows suit work you can name; recurring windows suit work nobody should have to think about.

Resist the urge to make every window recurring "just in case". A standing two-hour window every night means two hours a day in which a real outage goes unnoticed.

Get the time zone right

Most maintenance mistakes are time zone mistakes. A window set to "02:00" in UTC starts at 03:00 or 04:00 in Central Europe, depending on the season, and at 21:00 or 22:00 the previous evening in New York.

Set the window in the time zone where the work is scheduled, using an IANA name such as Europe/Berlin or America/New_York, not a fixed offset like UTC+1. A named zone follows daylight saving time changes, so a recurring window at 02:00 local time stays at 02:00 local time all year. A fixed offset drifts by an hour twice a year.

For one-off windows created from scripts, use Unix timestamps. They are unambiguous and avoid the question entirely.

Which monitors to include

Include:

The services the work touches directly.
Services that depend on them and will fail as a side effect. A database upgrade takes down the API, and with it the API health check and any keyword check on pages that load data.
Heartbeat monitors for jobs that will not run during the work.

Leave out everything else. If you are patching the API servers, your marketing site and its SSL checks should keep running.

One subtlety with heartbeats: a window skips the check, but it does not move the heartbeat's deadline. If a job was due to ping during the window and does not, the first check after the window sees a missed ping and alerts. Make the window long enough for the job to run once the work is done, or run the job manually afterwards.

A window that covers "all monitors" also covers monitors you add later. That is handy for a standing patch window on a single server, and surprising if you forget the window exists.

How a window affects uptime and SLA reporting

In PingRobot, monitors covered by an active window are not checked: no request is made, no result is recorded and no alert is sent. Uptime is calculated from recorded checks, so the window counts neither as up nor as down. The same is true for SLA targets on status pages: maintenance does not count against the SLA.

On a public status page, covered monitors show as under maintenance while the window is active, instead of down.

Be honest about what this means. Excluding maintenance from uptime is standard practice, and most SLA definitions allow for scheduled maintenance, but usually only when it is announced in advance and kept within agreed limits. If your contract says maintenance must be announced 72 hours ahead, a window you create five minutes before a deploy may keep your uptime figure clean while your customer still counts it as downtime. Check what your SLA actually says, and see uptime percentage explained for how much downtime each target allows.

Announce maintenance on your status page

The window controls your monitoring. Customers need a separate message. On a status page, that is a maintenance announcement with a lifecycle:

Scheduled, posted ahead of time: what is affected, when, in which time zone, and what users will notice.
In progress, when the work starts.
Completed, when it is done and verified.

A notice for the first step might read:

Scheduled maintenance: database upgrade
Sunday, March 7, 02:00–03:00 CET (01:00–02:00 UTC)
Checkout and order history may be unavailable for up to 15 minutes during
this window. Browsing the store is not affected.

Give a time range, a time zone and the user-visible effect. "Maintenance on our infrastructure" tells nobody whether to worry. Post it well before the work: a day or more for anything that affects customers, longer if your contracts require it. If you have status page email subscribers, that is the moment to notify them. More wording is in incident communication templates.

A deploy script that opens and closes a window

For deploys, create a one-off window at the start and delete it at the end, so monitoring resumes the moment the deploy finishes instead of when the window would have expired. This example uses the REST API (see the API docs) with curl and jq:

#!/usr/bin/env bash
set -euo pipefail

API=https://pingrobot.io/api/v1
AUTH="Authorization: Bearer $PINGROBOT_KEY"
NOW=$(date +%s)

# Open a 15-minute window for the API and checkout monitors.
WINDOW_ID=$(curl -fsS "$API/maintenance" -H "$AUTH" -H "Content-Type: application/json" \
  -d "{\"name\":\"Deploy ${GIT_SHA:-manual}\",\"repeat\":\"once\",\"startAt\":$NOW,\"endAt\":$((NOW + 900)),\"monitorIds\":[12,13]}" \
  | jq -r '.window.id')

# Close it however the script exits, success or failure.
trap 'curl -fsS -X DELETE "$API/maintenance/$WINDOW_ID" -H "$AUTH" > /dev/null || true' EXIT

./deploy.sh
./smoke-test.sh

Three details matter here. The trap deletes the window even if the deploy fails, so a broken release is reported by the next check instead of hiding until the window runs out. The fixed 15-minute end time is a safety net: if the runner dies and the trap never runs, monitoring still comes back on its own. And the window covers specific monitor ids, not all of them.

Use a read-and-write key stored in your CI's secret store, and keep it separate from any read-only key you use for dashboards.

Common mistakes

Windows that are too wide. Two hours "to be safe" for a ten-minute job means an hour and fifty minutes without monitoring. Size the window to the work plus a margin.
Covering every monitor. Unrelated outages during the window go unnoticed.
Fixed UTC offsets for recurring work. The window drifts an hour when daylight saving time changes.
Pausing monitors by hand instead. A paused monitor stays paused until someone resumes it. A window ends on schedule.
Forgetting the status page. Your team knew; your customers saw errors and opened tickets.
Not marking maintenance complete. A "scheduled" notice that is never updated makes the status page look abandoned.
Forgetting old recurring windows. Review them when infrastructure changes. A weekly window for a server you retired months ago now hides failures on whatever replaced it.

Start monitoring free — 10 monitors, no credit card.