Uptime Kuma не шлёт уведомления: причины и решение

MAATRIX

Монитор горит красным, история падений заполняется, а в Telegram и на почте тишина. Чаще всего канал уведомлений исправен — Uptime Kuma его просто не вызвала: уведомление не привязано к монитору, монитор ещё висит в PENDING или попал в окно обслуживания. Разберём слои по порядку — с текстами ошибок, запросами к базе и проверкой сети из контейнера.

Три звена, где теряется уведомление

Между падением сайта и сообщением в мессенджере три независимых звена, и жалоба «uptime kuma уведомления не приходят» одинаково звучит при поломке любого.

• Событие — Kuma шлёт сообщение не на каждый неудачный удар, а только на смену состояния; в базе такой удар помечен флагом important = 1.
• Привязка — у монитора свой список каналов, и канал, созданный в настройках, сам по себе ни к одному монитору не относится.
• Доставка — провайдер (Telegram, SMTP, вебхук) принимает или отвергает запрос.

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

Дальше лог контейнера:

docker logs uptime-kuma --since 24h 2>&1 | grep -i "Cannot send notification"
docker logs uptime-kuma --since 1h  2>&1 | grep -E "\[MONITOR\] (WARN|ERROR)"

Первая находит провал доставки — [MONITOR] ERROR: Cannot send notification to tg-alerts и стек с причиной. Вторая показывает жизнь монитора:

2026-08-27T21:14:03+00:00 [MONITOR] WARN: Monitor #7 'shop-front': Failing:
timeout of 48000ms exceeded | Interval: 60 seconds | Type: http |
Down Count: 1 | Resend Interval: 0

Down Count — сколько неудач подряд накопилось, Resend Interval — повтор уведомления. Строк WARN нет вовсе — монитор не падал, искать надо не в уведомлениях.

Канал не привязан к монитору

Самая частая причина молчания при работающем Test. Связь «монитор ↔ канал» лежит в отдельной таблице и создаётся только явно; в интерфейсе за неё отвечают две галочки, которые постоянно путают:

• Default enabled — канал включится только у мониторов, созданных после этого.
• Apply on all existing monitors — единственная галочка, которая проставит канал уже созданным мониторам.

В карточке монитора список каналов с чекбоксами, и галочка обязательно сохраняется кнопкой Save. Проверять десятки мониторов кликами бессмысленно — спросите базу. Kuma держит SQLite в /app/data/kuma.db в режиме WAL, поэтому копировать надо два файла, иначе увидите устаревший снимок:

docker cp uptime-kuma:/app/data/kuma.db     /tmp/kuma.db
docker cp uptime-kuma:/app/data/kuma.db-wal /tmp/kuma.db-wal
sqlite3 /tmp/kuma.db "
SELECT m.id, m.name, m.active, COALESCE(n.name,'--- НЕТ КАНАЛА ---') AS notif
FROM monitor m
LEFT JOIN monitor_notification mn ON mn.monitor_id = m.id
LEFT JOIN notification n ON n.id = mn.notification_id
ORDER BY m.id;"

Вывод:

7|shop-front|1|tg-alerts
8|api-gateway|1|--- НЕТ КАНАЛА ---
9|db-backup|0|tg-alerts

Монитор 8 никого не уведомит, у монитора 9 active = 0 — он на паузе и проверок не выполняет. Оба случая в панели выглядят безобидно.

Отдельная ловушка — восстановление из бэкапа: при импорте JSON Kuma заводит уведомления заново с новыми id, и часть связей теряется — каналы есть, а у мониторов пусто. На ветке 2.x поверх MariaDB файла kuma.db нет, но схема та же.

Событие не наступило: PENDING, Retries и «важные» удары

Связь есть, канал живой, а уведомления нет или оно опаздывает на минуты. Виновата логика состояний.

Kuma уведомляет только на смену состояния. Пока монитор непрерывно красный, повторов не будет: Resend Notification if Down X times по умолчанию равно 0. Отсюда классика — сервис лежит третьи сутки, а в чате тихо.

Retries переводят монитор в PENDING, а не в DOWN. При Retries > 0 первая неудача падением не считается: монитор желтеет, уведомление не уходит. Считаем: интервал 60 с, Retries 3, Heartbeat Retry Interval 60 с.

До трёх минут молчания при исправной настройке — не баг, а плата за защиту от ложных срабатываний. Нужен алерт за минуту: Retries 1 и интервал 30 секунд, но будьте готовы к шуму.

Монитор уже лежал, когда вы привязали канал. Состояние не менялось, «важного» удара не было — уведомления не будет. Нажмите Pause и Resume: перезапуск даёт первый удар, который Kuma считает важным.

Что было на самом деле, видно в таблице ударов (0 — DOWN, 1 — UP, 2 — PENDING, 3 — MAINTENANCE):

sqlite3 /tmp/kuma.db "SELECT datetime(time), status, important, substr(msg,1,40)
FROM heartbeat WHERE monitor_id = 7 ORDER BY id DESC LIMIT 8;"

Если в колонке important одни нули, Kuma никого уведомлять не пыталась — разбираться с Telegram бессмысленно. Проверьте заодно Upside Down Mode: он инвертирует смысл проверки и шлёт алерты, когда всё хорошо.

Тишина по расписанию: обслуживание и часовой пояс

Функция Maintenance гасит уведомления молча: монитор во время окна получает статус 3, красится синим, падения фиксируются, но никого не будят. Забытое окно с cron-расписанием — типичная причина «уведомления перестали приходить неделю назад».

sqlite3 /tmp/kuma.db "SELECT id, title, active, strategy FROM maintenance;"

strategy бывает manual, single, recurring-interval, recurring-weekday, cron. Опаснее всего manual: включили окно на время работ и не выключили — висит бесконечно.

Дальше время. У окна свой часовой пояс, и если контейнер живёт по UTC, а интервал задавали по московскому времени, окно откроется на три часа раньше. Сверьте timedatectl на хосте и docker exec uptime-kuma date внутри: контейнер по умолчанию в UTC, лечится переменной -e TZ=Europe/London и перезапуском. В выводе timedatectl должно быть System clock synchronized: yes, иначе ставьте chrony.

Из контейнера не выйти: DNS, IPv6 и TLS

Если Test падает, причина почти всегда сетевая, и её класс виден по ошибке Node.js:

• Error: getaddrinfo EAI_AGAIN api.telegram.org — не резолвится имя. У контейнера свой DNS от демона Docker: нужен --dns 1.1.1.1 при запуске или "dns": ["1.1.1.1"] в /etc/docker/daemon.json плюс systemctl restart docker.
• connect ETIMEDOUT либо ENETUNREACH 2606:4700:... — Node получил AAAA-запись и ушёл в IPv6, которого на сервере нет.
• connect ECONNREFUSED 127.0.0.1:587 — в канале указан localhost, но внутри контейнера это сам контейнер. Для сервиса на хосте берите host.docker.internal (с --add-host=host.docker.internal:host-gateway) или IP docker-моста, обычно 172.17.0.1.
• Error: self-signed certificate in certificate chain — на пути инспектирующий прокси или самоподписанный сертификат вебхука. Примонтируйте корневой сертификат и добавьте -e NODE_EXTRA_CA_CERTS=/certs/corp-root.crt. Галочка «Ignore TLS Error» у SMTP отключает проверку целиком: компромисс, а не норма.

Связность проверяйте из сетевого пространства Kuma, а не с хоста: маршруты и DNS у них разные. Своего curl в образе может не оказаться (exec: "curl": executable file not found), подключите к тому же namespace отдельный контейнер:

docker run --rm --network container:uptime-kuma curlimages/curl:8.11.1 \
  -sS -m 10 -o /dev/null -w 'code=%{http_code} t=%{time_total}\n' \
  https://api.telegram.org

Нормальный ответ с европейского узла — code=302 и t меньше 0.1. Таймаут значит, что наружу монитор не ходит, и правки токена не помогут. Сам ufw уведомления не ломает — он по умолчанию режет только входящие (allow (outgoing)), — но трафик контейнеров идёт мимо его цепочек: смотрите iptables -L DOCKER-USER -n -v.

Разбор по каналам: SMTP, вебхук, Apprise, Telegram

Когда сеть в порядке, остаётся провайдер — ошибку он возвращает дословно.

SMTP. Самый капризный канал:

• connect ETIMEDOUT 77.88.21.158:25 — исходящий 25-й порт закрыт почти у всех провайдеров как антиспам-мера. Используйте 587 со STARTTLS.
• SSL routines:ssl3_get_record:wrong version number — порт и режим шифрования не совпали. Порт 465 требует включённой галочки «Secure» (implicit TLS), порт 587 — выключенной.
• 535 5.7.8 Error: authentication failed и 534-5.7.9 Application-specific password required — подставлен обычный пароль ящика, а Gmail, Яндекс и Mail.ru требуют пароль приложения.
• 550 5.7.1 Sender address rejected: not owned by user — поле From не совпадает с логином SMTP.

Вебхук. Kuma умеет три формата тела: application/json, multipart/form-data и произвольный шаблон, а приёмник (n8n, Make, самописный обработчик) понимает один. Если он отвечает 200 OK и молча выбрасывает payload, Kuma считает доставку успешной — проверять надо на приёмнике. У Discord характерный ответ {"message": "Unknown Webhook", "code": 10015} при удалённом URL и 429 Too Many Requests при шторме алертов.

Apprise. В Docker-образе предустановлен, а при установке из исходников через npm канал упадёт с Error: spawn apprise ENOENT: вызывается внешний бинарник, которого в системе нет. Лечит pipx install apprise.

Telegram. У канала есть поле Message Thread ID: для форумного супергруппового чата без него прилетит Bad Request: message thread not found при верных токене и chat_id. А chat_id супергруппы начинается с -100 — сокращённый вариант даёт Bad Request: chat not found. Проверьте мимо Kuma, тем же контейнером с curl: https://api.telegram.org/bot<ТОКЕН>/sendMessage?chat_id=<ID>&text=ping. Ответ {"ok":true,...} значит, что канал рабочий и виноваты привязка или событие.

Какой сервер под Uptime Kuma брать в MAATRIX

Есть сценарий, при котором никакая настройка не спасёт: уведомления не приходят, потому что упал сам сервер с Kuma. Мониторинг не должен стоять рядом с тем, что мониторит.

Минимум: 1 vCPU, 1 ГБ RAM, 20 ГБ NVMe. Хватает на 20–30 мониторов. В простое Kuma занимает 130–200 МБ RSS (docker stats --no-stream uptime-kuma). Честное ограничение — база: каждый удар это запись в SQLite, и 40 мониторов с интервалом 60 секунд дают 57 600 строк в сутки. При заводской глубине хранения в 180 дней это около 10 миллионов строк и больше гигабайта файла, а на медленном диске задержки записи начинают сдвигать сами проверки. Сразу уменьшите хранение до 30–60 дней в Settings → Monitor History и нажмите там же Shrink Database — кнопка выполняет VACUUM.

Комфортный вариант: 2 vCPU, 4 ГБ RAM, 40–60 ГБ NVMe. Сотня мониторов, Nginx с Let's Encrypt перед панелью, публичная статус-страница и бэкапы каталога /app/data.

Локация — Великобритания (Лондон). Важен не столько пинг, сколько беспрепятственный исход наружу: с лондонского адреса api.telegram.org, SMTP-релеи и вебхуки в Slack или Discord отвечают штатно, без обходных путей. RTT до европейских площадок — первые десятки миллисекунд, до Москвы 40–60 мс, для проверок раз в минуту более чем достаточно. Плюс GDPR-периметр, если статус-страница публичная.

Честный минус: следя за российским сайтом из Лондона, вы смотрите через трансграничный маршрут, и часть таймаутов будет говорить о канале, а не о сайте. Лечится не сменой локации, а параметрами — Retries 2–3 и таймаут выше заводских 48 секунд. Нужен взгляд изнутри РФ — ставьте две Kuma в разных локациях (UK и RU), и пусть каждая пингует push-монитор соседа: */2 * * * * curl -fsS -m 10 "https://kuma2.example.com/api/push/<token>".

Разворачивать вручную не нужно: Uptime Kuma есть в каталоге apps.maatrix.io и ставится автоматически при заказе, на Ubuntu и Debian. Адрес панели и учётные данные появятся в личном кабинете, в разделе «Доступ». Оплата картами российских банков, по СБП или криптовалютой — иностранная карта для британской локации не нужна. После первого входа заведите канал, отметьте «Apply on all existing monitors» и нажмите Test: ровно эти два шага чаще всего и пропускают.

Частые вопросы