Maintenance windows: muting alerts for scheduled work

A maintenance window is a scheduled time interval during which Tracker.ru keeps probing your URL but does not dispatch down notifications. Alerts about a down status are suppressed for probes that fall inside the window; downtime within the window is not counted as unplanned downtime.

This is needed so that planned work — deploys, database migrations, infrastructure upgrades, TLS certificate rotations, nightly restarts — does not turn into a flood of false Telegram alerts and does not pollute your uptime statistics. You declare in advance "the site may be unavailable during this hour", and monitoring respects it.

4 window types

The type field accepts one of four values (the enum lives in migration 2026_02_13_204016_create_maintenance_windows_table.php). The type determines which extra fields are required:

The start_time field is stored as TIME (HH:MM:SS), duration_minutes as unsignedSmallInteger (up to 65535 minutes; in practice rarely longer than a day). active = true by default — a window can be temporarily disabled without deletion by setting active = false (useful when planned work is paused).

If day_of_month is greater than the number of days in the current month (31 in February), the window simply does not activate that month — without an error.

How to configure

On the URL page in your dashboard locate the "Maintenance windows" block. Click "Add window" and in the form:

1. Choose the type (once, daily, weekly, monthly).
2. Fill the fields required for that type (see the table above).
3. Specify the start time and duration in minutes.
4. Click "Save".

The window becomes active immediately. The list of windows for a URL is displayed with the type and schedule; inactive windows are shown in grey.

API

Maintenance windows can be managed through the REST API. The endpoint accepts the type, time, and duration; the fields are validated against the same contract as the UI.

# Weekly window: every Sunday 04:00 for 60 minutes
curl -X POST https://tracker.ru/api/v1/urls/123/maintenance-windows \
  -H "Authorization: Bearer <api_token>" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "weekly",
    "day_of_week": 0,
    "start_time": "04:00:00",
    "duration_minutes": 60,
    "active": true
  }'

# One-time window: migration on May 12 at 03:00 for 90 minutes
curl -X POST https://tracker.ru/api/v1/urls/123/maintenance-windows \
  -H "Authorization: Bearer <api_token>" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "once",
    "scheduled_date": "2026-05-12",
    "start_time": "03:00:00",
    "duration_minutes": 90
  }'

The API is available on plans with has_api enabled (Pro). Managing windows through the UI does not require API access.

Timezone

All start_time values are interpreted in the timezone of your profile (User.tz, defaults to Europe/Moscow). This applies both to the UI (the form shows local time) and to the Go checkers (the IsURLInMaintenance(urlID, userTz) function takes the user's TZ and applies it to the window schedule).

Practical implications:

• One user — one TZ. If your team operates across timezones, the window runs in the URL owner's TZ.
• Daylight saving. Russia does not use DST, so the issue surfaces only for users with European country TZs. At the moment of clock change, windows shift together with local time.
• Window crossing midnight. If start_time = 23:30 and duration_minutes = 60, the window closes at 00:30 the next day. The behaviour is correct.

The profile timezone is changed in /my/profile and applies to new probes from the next round onwards.

Alert behaviour

What happens inside a window:

• Probes keep running. TCP/HTTP checkers do not stop — we keep collecting history in check_log and computing statistics.
• down notifications are not dispatched. If the URL fails inside a window, the alert to Telegram/MAX/Email/Webhook does not go out. The IsURLInMaintenance function is invoked before sending in each notification worker (telegram, email, webhook).
• Recovery notifications are also suppressed if the first successful probe after recovery falls inside the window. This avoids reporting a "successful recovery" in the middle of a deploy — the real state is not yet confirmed.

When the window ends:

• If by that point the URL has recovered, the behaviour depends on whether a down alert was sent BEFORE the window. If the failure happened inside the window and ended inside the window, the user receives neither an alert nor a recovery notification (which is exactly what we want).
• If the failure outlives the window and continues beyond it, the next probe after the window ends goes through the standard notification pipeline and a down alert is dispatched.

Plan limits

The number of maintenance windows per user is capped by the plan (the max_maintenance_windows field in PlanSeeder):

The limit is enforced via PlanLimitService::canAddMaintenanceWindow when a window is created. On the Free plan the feature is fully disabled — regular use requires Basic or Pro. Three windows on Basic are enough for the typical "daily backup + weekly rotation + one-off migration" scenario; ten windows on Pro cover more complex schedules.

The limit is shared across all of the user's URLs: a single endpoint can have several windows, but the total count must not exceed the plan limit.

Related articles

• /docs/features/tcp-monitoring?lang=en — TCP monitoring for database and queue ports.
• /docs/features/keyword-check?lang=en — keyword lookup inside the HTML response.
• /docs/notifications/telegram?lang=en — Telegram notification setup.
• /docs/notifications/webhooks?lang=en — webhooks with HMAC-SHA256 signatures.