Активные мониторы — HTTP-эндпоинт и TCP-порт

В отличие от heartbeat-а, где cron сам подтверждает работоспособность, активный монитор работает наоборот: Notifly сам периодически дёргает указанный URL или TCP-порт. Это удобно, когда:

сервис стоит на чужом сервере или у вас нет доступа править его cron;
нужно проверять внешние зависимости — платёжные шлюзы, чужие API, IoT-устройства;
вы хотите быть уверены не только, что cron на сервере жив, но и что сам сервис принимает соединения (порт открыт, TLS не протух, healthcheck отвечает).

Сценарий 1: HTTP healthcheck сайта

Создать монитор:
  Тип:           HTTP(S)
  Цель:          https://example.com/health
  Период:        60 сек
  Таймаут:       10 сек
  Подряд неудач: 3      ← чтобы не реагировать на единичный сетевой джиттер
  Ожид. код:     0      ← любой 2xx
  Alert:         "Сайт example.com недоступен!" приоритет 9
  Recovery:      "Сайт example.com снова отвечает."

При первой же серии из 3 подряд неуспешных GET-ов прилетит push с заголовком Сайт example.com недоступен! и расшифровкой ошибки (status=502 или dial tcp: i/o timeout). Когда сайт ответит снова — вторым push-ом «снова отвечает».

Сценарий 2: TCP-порт базы данных

Создать монитор:
  Тип:           TCP-порт
  Цель:          db.example.com:5432
  Период:        30 сек
  Таймаут:       5 сек
  Подряд неудач: 2
  Alert:         "Postgres-реплика не принимает соединения!" приоритет 10
  Recovery:      "Реплика снова отвечает на 5432."

Notifly раз в 30 секунд делает net.Dial("tcp", host:port) с таймаутом 5 секунд. Удобно для:

БД — Postgres :5432, MySQL :3306, MongoDB :27017, Redis :6379;
mail/SMTP — :25, :465, :587;
SSH-bastion — :22 (если на нём что-то слушает — порт открыт);
кастомных gRPC/TCP-демонов, у которых нет HTTP-healthcheck.

TCP-проверка не делает протокольного handshake — только подтверждает, что порт принимает соединение. Если нужно убедиться, что отвечает именно сервис, выберите протокольную проверку: postgres, mysql, redis, smtp, imap, pop3, ssh или dns — см. типы мониторов.

Проверки идут из облака Notifly, поэтому цель должна быть доступна из интернета: приватные, loopback и link-local адреса мониторить нельзя. Для внутренних сервисов подойдёт heartbeat изнутри сети.

Сценарий 3: SSL-сертификат на грани

Для сертификатов есть отдельный тип монитора «SSL-сертификат не истекает» (kind: "ssl"): он проверяет цепочку доверия и имя хоста и предупреждает заранее — по умолчанию за 14 дней до истечения (настраивается 1–365):

Создать монитор:
  Тип:           SSL-сертификат
  Цель:          example.com          ← или example.com:8443
  Период:        1 час
  Предупреждать: за 21 день
  Alert:         "Сертификат example.com скоро истекает!" приоритет 8

Обычный HTTP-монитор тоже упадёт на протухшем сертификате (x509: certificate has expired), но только когда станет уже поздно; SSL-монитор предупредит заранее.

Чем это отличается от heartbeat-а

	Heartbeat	Активный монитор
Кто инициирует	Ваш cron / сервис	Сама Notifly
Сетевая модель	Inbound (Notifly слушает)	Outbound (Notifly стучится)
Когда полезен	Контролировать факт запуска cron	Контролировать доступность сервиса
Защищает от	Cron не запустился, скрипт повис	Упал процесс, закрыт порт, протух SSL
Требует	Доступ к cron-файлу/коду	Просто публичный URL/host:port

Часто оба используют в паре: heartbeat — что бэкап запустился, монитор — что сам сервис, который он бэкапит, всё ещё отвечает.

Создание из MCP

> Поставь активный монитор на https://api.notifly.ru/health,
  проверять каждые 30 секунд, алёрт после 3 подряд неудач,
  с recovery-сообщением «API снова работает».

См. полный список параметров.