Uptime Kuma: честный обзор — 33 типа проверок, 100+ каналов уведомлений и одна точка, из которой всё видно

Самый популярный self-hosted мониторинг в мире: 90 тысяч звёзд на GitHub, 182 миллиона скачиваний образа, версия 2.x с поддержкой MariaDB. Разбираем на цифрах, что он умеет, чего не умеет принципиально, сколько на самом деле стоит «бесплатный» мониторинг и в какой схеме Kuma работает лучше всего.

Uptime Kuma — открытая программа для мониторинга доступности, которую вы разворачиваете на своём сервере: она сама опрашивает сайты, порты, базы и контейнеры и присылает уведомления в сотню каналов. Лицензия MIT, код на Node.js, один процесс, данные в SQLite или MariaDB. Главное архитектурное свойство — проверки идут из одной точки, той, где Kuma установлена.

Проект в цифрах

Kuma — не «поделка энтузиаста», а один из самых живых проектов в своей нише. Все числа ниже сняты с GitHub API и Docker Hub на середину сентября 2026 года.

В ветке master уже лежит 3.0.0-beta.0 с переездом на TypeScript и требованием Node 26 — на Docker Hub собираются теги nightly3. Релиза пока нет, но направление понятно: проект не стоит.

Версия 2.0: что изменилось и где ловушка

Двойка вышла в октябре 2025 года после года беты и принесла главное — внешнюю базу данных. Но у неё есть особенность, на которой спотыкается каждый второй: Docker-тег latest до сих пор указывает на 1.23.17. Чтобы получить двойку, нужен тег 2.

Установка: пять минут, три варианта образа

# Одной командой
docker run -d --restart=unless-stopped -p 3001:3001 \
  -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:2

# compose.yaml из репозитория
services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    restart: unless-stopped
    volumes:
      - ./data:/app/data
    ports:
      - "3001:3001"

# Без Docker: Node.js 20.4+ и pm2
git clone https://github.com/louislam/uptime-kuma.git && cd uptime-kuma
npm run setup
npm install pm2 -g && pm2 install pm2-logrotate
pm2 start server/server.js --name uptime-kuma

# Обновление
docker compose pull && docker compose up -d --force-recreate

Все данные живут в /app/data: файл kuma.db плюс журналы -wal и -shm. Файловая система должна поддерживать POSIX-блокировки — SQLite на NFS или SMB рано или поздно повредит базу. Официальных минимальных требований к CPU и памяти у проекта нет; образы собираются под amd64, arm64 и armv7.

33 типа мониторов

Здесь Kuma сильнее большинства облачных сервисов: она умеет ходить не только снаружи в сайт, но и внутрь инфраструктуры — в базы, очереди, контейнеры и игровые серверы. Список из исходников версии 2.5.4.

Монитор Globalping заслуживает отдельного слова: это единственный способ заставить Kuma проверить сайт не с собственного сервера, а через чужие пробы по миру. Работает только для HTTP, ping и DNS и требует токен внешнего сервиса — то есть часть проверок уезжает в облако, от которого вы как раз хотели уйти.

Уведомления: сто с лишним провайдеров и что из них живёт в России

README скромно обещает «90+», по коду версии 2.5.4 провайдеров больше сотни. Для российского администратора интересна не общая цифра, а вот эта выборка.

Уведомление можно повторять каждые N неудачных проверок (resend interval) и гонять через прокси. Но эскалации как класса нет: «сначала Telegram, а через полчаса позвонить, если не поднялось» — это уже внешняя система поверх Kuma.

Статус-страницы и окна обслуживания

Публичные страницы состояния — сильная сторона Kuma и частая причина её выбора. Несколько страниц, свои домены, инциденты с Markdown, RSS-лента, свой CSS, тёмная тема, счётчики аналитики. Окна обслуживания — с 1.19: разовое, по cron, по интервалу, по дню недели или месяца, со своим часовым поясом; на время окна мониторы синие, а на странице висит баннер.

Настройки проверки, которые стоит знать до первого инцидента

Авторизация в HTTP-мониторах закрывает почти всё: Basic, Bearer, OAuth2 client credentials, NTLM, mTLS; плюс свои заголовки, тело запроса и прокси на монитор. Для сравнения интервалов с облачным подходом полезно помнить, как считается время обнаружения инцидента: оно всегда равно интервалу проверки плюс повторы.

Под капотом: SQLite против MariaDB

Kuma — один процесс Node.js. Пока мониторов десятки, о базе можно не думать. Дальше начинаются нюансы, и они хорошо задокументированы в issues проекта.

Честные ограничения

Все семь пунктов ниже — не баги, а сознательные решения проекта. Спорить с ними в issues бесполезно, это проверено сотнями людей до вас.

Первый пункт — принципиальный, и о нём вспоминают уже после установки. Kuma стоит на вашем VPS в одном дата-центре одного оператора. Она не увидит, что сайт недоступен для абонентов другого провайдера, что маршрут в регион оборвался или что падение видно только из части страны. А если ляжет сам VPS с Kuma — уведомлений не будет вообще, потому что некому их отправлять.

Безопасность: 16 бюллетеней за три года

Для проекта такого размера это нормальная статистика, но она задаёт правило эксплуатации: админку Kuma нельзя светить в интернет без дополнительной защиты.

Большинство уязвимостей требуют авторизации — то есть опасны, когда админка доступна снаружи и пароль слабый. Два конкретных шага: включить 2FA (есть из коробки) и закрыть порт 3001 всем, кроме reverse-proxy. С версии 2.5.0 проект ввёл 14-дневную задержку на обновление npm-зависимостей против supply-chain атак — редкий для open source уровень дисциплины.

Сколько стоит бесплатный мониторинг

Kuma бесплатна как программа, но не как система. Посчитаем на условном примере: 30 сайтов, один администратор. Цифры ниже — расчётные допущения, подставьте свои.

Час администратора — самая дорогая строка, и именно её обычно не считают. При ставке даже в 1 500 ₽ за час «бесплатная» Kuma обходится в 2 500 ₽ в месяц. Это не аргумент против неё: для тех, кому нужны проверки баз, очередей и контейнеров изнутри периметра, альтернатив такого качества за эти деньги нет. Это аргумент против слова «бесплатно» в расчётах.

Кому подходит, а кому нет

Uptime Kuma и Пруфен: где что сильнее

Это не «кто лучше», а «кто для чего». Kuma смотрит на инфраструктуру изнутри и бесплатна как код; облачный сервис смотрит на сайт снаружи глазами пользователей и берёт на себя эксплуатацию.

Схема, в которой Kuma работает лучше всего

Самый устойчивый вариант, к которому приходят почти все, кто эксплуатирует Kuma дольше года, — разделение обязанностей. Kuma стоит внутри периметра и следит за тем, до чего облачный сервис не дотянется: базы, очереди, контейнеры, внутренние API, сервисы на localhost. Внешний мониторинг следит за тем, чего не видит Kuma: как сайт открывается из разных регионов, не заблокирован ли он, не попал ли IP в спам-листы, не истёк ли сертификат глазами реального посетителя. И — отдельным пунктом — за самим сервером с Kuma, потому что упавший мониторинг молчит так же, как здоровый.

Технически это два монитора со стороны облака: HTTP-проверка страницы статуса Kuma и TCP-проверка порта 3001 или того, что стоит перед ним. Если оба молчат — вы узнаёте о проблеме от внешней системы, а не утром от клиентов.

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

Можно ли сделать несколько точек проверки на нескольких Kuma? Формально да: поднять инстансы в разных дата-центрах и мониторить одно и то же. Но у каждой будет своя история, свои уведомления и свой процент аптайма — сводить их придётся руками или через Grafana. Кворума «упало для двух из трёх» не получится.

Telegram заблокирован у провайдера — уведомления перестанут приходить? В настройках Telegram-провайдера есть поле Server URL: туда подставляется адрес собственного прокси Bot API, и уведомления идут через него. Либо перевести оповещения в Макс, который в Kuma есть с версии 2.3.0.

Что будет, если обновить 1.23 до 2.x через тег latest? Ничего: latest по-прежнему указывает на 1.23.17. Чтобы получить двойку, нужно явно указать тег 2, предварительно сделав бэкап каталога data — миграция схемы необратима.

Есть ли мобильное приложение? Официального нет. Веб-интерфейс работает как PWA, с версии 2.1.0 есть Web Push. Сторонние клиенты: KumaAlert и Wuma для iOS, Uptime Kuma Manager для iOS и Android, OpenKuma для Android с открытым кодом.

Можно ли управлять мониторами из кода? Стабильного REST API нет. Рабочие обходы: AutoKuma создаёт мониторы из Docker-лейблов, Python-библиотека uptime-kuma-api работает через Socket.io, но официально совместима только с 1.17–1.23. Для чтения метрик — Prometheus-эндпоинт по API-ключу.

Если выбираете между несколькими облачными сервисами, а не между облаком и self-hosted, — у нас есть отдельный разбор российских альтернатив UptimeRobot с таблицей возможностей.