maintenance-windows

name	maintenance-windows
description	Schedule one-off or recurring maintenance windows that suppress alerts for planned downtime, as an alternative to bulk-pause.
tags	["maintenance-window","scheduled","downtime","alerts","uptimerobot"]

Maintenance windows

Preflight — read first. If you cannot see any uptimerobot:* MCP tools in your tool list, invoke the uptimerobot:setup skill before doing anything else. Do not tell the user the MCP is misconfigured — setup's Step 0 detects the common case (server connected, tools loaded after session start) and resolves it without re-keying.

Requires the maintenance-window plan feature.

Decision: maintenance window vs. bulk-pause

Both stop alert noise during planned downtime, but they work differently:

	Maintenance window	bulk-pause
What changes	Alerts only — monitor keeps checking and its state stays visible	Monitor itself stops checking (status: PAUSED)
Timing	Scheduled in advance, can recur	Immediate, manual resume
Resume cap risk	None — monitor was never paused	Resuming can hit -28001 monitor_limit_exceeded
Best for	Known, recurring, or future-dated downtime (deploy windows, patching schedule)	Ad-hoc, right-now, or a monitor that needs to fully stop

Default to a maintenance window whenever the downtime is planned ahead of time or repeats. Use bulk-pause for "pause it right now" requests.

Creating a window

{
  "name": "Weekly DB patching",
  "interval": "weekly",
  "date": "2026-07-06",
  "time": "02:00:00",
  "duration": 90,
  "days": [1],
  "monitorIds": [800111, 800222]
}

• date/time are the first occurrence; time is UTC — confirm the user's intended timezone and convert before calling.
• days is required for weekly (1–7, ISO weekday) and monthly (1–31, or -1 for "last day of the month") recurrence. Omitting it on a recurring window is a validation error, not a silent default.
• duration is minutes the window stays active from the daily start time — not an end date.
• autoAddMonitors: true includes every monitor, including ones created later. Confirm with the user before using it — it's easy to end up suppressing alerts for something unrelated.

The monitor-linkage asymmetry

Unlike tags, the window owns the relationship, not the monitor. create-monitor accepts maintenanceWindowsIds at creation time, but update-monitor has no equivalent field — you cannot attach an existing monitor to a window from the monitor side after creation.

To add or remove monitors from an existing window, update the window instead:

{ "maintenanceWindowId": 700123, "monitorIds": [800111, 800222, 800333] }

This is a full replacement of the window's monitor list (same pattern as tagNames/assignedAlertContacts elsewhere) — read the current list via get-maintenance-window first if you're adding one monitor rather than replacing the set.

Pausing / resuming a window without deleting it

{ "maintenanceWindowId": 700123, "status": "paused" }

Use this when a scheduled window needs to be called off for one occurrence without losing the recurrence config. Flip back with status: "active".

Common mistakes

• Forgetting days on a weekly/monthly window.
• Treating time as the user's local timezone — it's UTC.
• Trying to attach a monitor to a window via update-monitor — that field doesn't exist there; update the window's monitorIds instead.
• Sending a partial monitorIds array on update-maintenance-window expecting a merge — it replaces the full set.
• Recommending a maintenance window to a plan that doesn't have the maintenance-window feature — check for -28002 subscription_limit_exceeded and suggest bulk-pause or a plan upgrade instead.
• Using a maintenance window for "stop this monitor entirely" — it suppresses alerts, not checks. Use update-monitor-status if the user wants the monitor to actually stop.

Related

• bulk-pause — the immediate/manual alternative.
• status-pages — pair a Maintenance-type announcement with the window.
• errors — -28002 for plan gating, -29001 for malformed recurrence params.