Tracker.ru / Документация

Окна обслуживания: заглушение алертов на плановое ТО

4 мин чтения
Обновлено 12 мая 2026

Окно обслуживания (maintenance window) — это запланированный временной интервал, в течение которого Tracker.ru продолжает проверять URL, но не отправляет уведомления о падении. Алерты о down-статусе подавляются для проверок, попавших в окно; downtime внутри окна не учитывается как незапланированный простой.

Это нужно, чтобы плановые работы — деплои, миграции БД, обновление инфраструктуры, ротация TLS-сертификатов, ночные перезагрузки — не превращались в шквал ложных алертов в Telegram и не портили статистику uptime. Вы заранее декларируете «вот в этот час сайт может быть недоступен», и мониторинг это уважает.

4 типа окон

Поле type принимает одно из четырёх значений (enum в миграции 2026_02_13_204016_create_maintenance_windows_table.php). Тип определяет, какие дополнительные поля обязательны:

Тип Когда повторяется Обязательные поля Пример
once Один раз scheduled_date, start_time, duration_minutes Миграция БД 12 мая 03:00, 90 минут
daily Каждый день start_time, duration_minutes Ночной бэкап в 02:00, 30 минут
weekly Каждую неделю в указанный день day_of_week (0–6, 0=воскресенье), start_time, duration_minutes По воскресеньям в 04:00, 60 минут
monthly Каждый месяц в указанное число day_of_month (1–31), start_time, duration_minutes 1-го числа в 03:00, 120 минут

Поле start_time хранится как TIME (HH:MM:SS), duration_minutes — unsignedSmallInteger (до 65535 минут, на практике редко больше суток). active = true по умолчанию — окно можно временно деактивировать без удаления, поставив active = false (полезно, когда плановое ТО приостановлено).

Если day_of_month указан больше, чем дней в текущем месяце (31 в феврале), окно в этом месяце просто не активируется — без ошибки.

Как настроить

На странице URL в личном кабинете найдите блок «Окна обслуживания». Нажмите «Добавить окно», в форме:

  1. Выберите тип (once, daily, weekly, monthly).
  2. Заполните обязательные для этого типа поля (см. таблицу выше).
  3. Укажите время начала и длительность в минутах.
  4. Нажмите «Сохранить».

Окно становится активным сразу. Список окон у URL отображается с указанием типа и расписания; неактивные окна показаны серым.

API

Окнами обслуживания можно управлять через REST API. Эндпоинт принимает тип, время и длительность; поля валидируются по тому же контракту, что и UI.

# Еженедельное окно: каждое воскресенье 04:00 на 60 минут
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
  }'

# Разовое окно: миграция 12 мая 03:00 на 90 минут
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
  }'

API доступен на тарифах с включённым has_api (Pro). Для управления через UI наличие API не требуется.

Часовой пояс

Все значения start_time интерпретируются в часовом поясе вашего профиля (User.tz, по умолчанию Europe/Moscow). Это касается и UI (форма показывает локальное время), и Go-чекеров (функция IsURLInMaintenance(urlID, userTz) принимает TZ юзера и применяет его к расписанию окна).

Практические следствия:

  • Один пользователь — один TZ. Если у вашей команды разные часовые пояса, окно работает по TZ владельца URL.
  • Переход на летнее время. Россия летнее время не использует, проблема возникает только для пользователей с TZ европейских стран. В моменты перевода стрелок окна смещаются вместе с локальным временем.
  • Окно через полночь. Если start_time = 23:30, duration_minutes = 60 — окно закроется в 00:30 следующих суток. Поведение корректное.

Часовой пояс профиля меняется в /my/profile и применяется к новым проверкам со следующего раунда.

Поведение алертов

Что происходит внутри окна:

  • Проверки идут как обычно. TCP/HTTP-чекеры не останавливаются — мы продолжаем собирать историю в check_log, считать статистику.
  • Уведомления о down не отправляются. Если URL упал внутри окна, алерт в Telegram/MAX/Email/Webhook не уходит. Функция IsURLInMaintenance вызывается перед отправкой в каждом из notification-воркеров (telegram, email, webhook).
  • Recovery-уведомления тоже не отправляются, если первый успешный чек после восстановления попадает в окно. Это нужно, чтобы не отчитываться об «успешном восстановлении» прямо в середине деплоя — реальное состояние ещё не подтверждено.

Когда окно заканчивается:

  • Если URL к этому моменту восстановился — поведение зависит от того, был ли отправлен down-алерт ДО окна. Если падение случилось внутри окна и закончилось внутри окна — пользователь не получит ни алерта, ни recovery (ровно то, что мы и хотим).
  • Если падение пережило окно и продолжается после — следующая проверка после окончания окна снова пройдёт через стандартный пайплайн уведомлений и down-алерт уйдёт.

Лимиты по тарифу

Количество окон обслуживания на одного пользователя ограничено тарифом (поле max_maintenance_windows в PlanSeeder):

Тариф Максимум окон
Free 0
Basic 3
Pro 10

Лимит проверяется через PlanLimitService::canAddMaintenanceWindow при создании окна. На Free-тарифе функция полностью отключена — для регулярного использования нужен Basic или Pro. На Basic трёх окон достаточно для типового сценария «ежедневный бэкап + еженедельная ротация + разовая миграция»; на Pro десять окон закрывают и более сложные расписания.

Лимит считается по всем URL пользователя суммарно: одна точка может иметь несколько окон, но общее количество не должно превышать тарифный лимит.

Связанные статьи