Мониторинг аптайма
Метод запроса
GET или POST. POST позволяет проверять эндпоинт, который принимает только запросы на запись (например, собственную проверку работоспособности у получателя вебхуков).
Проверка TCP-порта
Не всё говорит по HTTP — база данных, почтовый сервер, игровой сервер. Вместо http(s):// укажите в URL tcp://host:port, и Dumza будет проверять, принимает ли этот порт соединение, вместо HTTP-запроса. Метод, ожидаемый статус, ключевое слово и порог времени отклика к TCP-проверке не применяются и скрыты в форме; алертинг, инциденты и всё остальное работают точно так же.
Ожидаемый код статуса
Любой эндпоинт, вернувший код, отличный от ожидаемого, считается недоступным. Это не ограничивается кодом 200 — многие API корректно возвращают 201, 204 и даже 401/503 при исправной работе (например, эндпоинт, который ДОЛЖЕН требовать авторизацию). Укажите тот статус, который ваш эндпоинт возвращает, когда он действительно работает исправно.
Проверка по ключевому слову
Можно дополнительно потребовать (или запретить) наличие определённого текста в теле ответа — это полезно для эндпоинтов, которые возвращают 200 даже когда что-то на странице сломано (например, CMS отдаёт общую страницу ошибки со статусом 200). Выберите «содержит», чтобы требовать текст, или «не содержит», чтобы проверка падала при его появлении (удобно для отлова баннера режима обслуживания, который приложение показывает, продолжая отвечать 200).
Порог времени отклика
Задайте максимально допустимое время отклика — и проверка, которая отвечает корректно, но слишком медленно, будет помечена как «degraded», а не «down». Это отображается на панели управления и учитывается в статистике аптайма, но НЕ открывает инцидент и не отправляет оповещение. «Degraded» — сигнал, за которым стоит следить, а не повод кого-то будить.
Интервал проверки
Как часто Dumza проверяет эндпоинт. На бесплатном тарифе проверка выполняется каждые 5 минут; на платных тарифах интервал может быть снижен вплоть до 1 минуты. Более короткий интервал означает более быстрое обнаружение сбоя ценой большего числа запросов к вашему серверу.
Тайминг оповещений: notifyAfter и повторные уведомления
Параметр «Оповестить после N сбоев подряд» определяет, сколько неудачных проверок подряд открывают инцидент (минимум 2 — чтобы избежать ложных срабатываний из-за одного сбоя). Отдельно параметр «Повторное уведомление каждые N минут» (необязательный, минимум 30) повторяет оповещение, пока монитор остаётся недоступен — полезно, если первое оповещение команда пропустила.
Значения статуса монитора
up — последняя проверка прошла успешно. down — открыт инцидент. degraded — отвечает, но медленнее заданного порога времени ответа, либо медленнее 10 секунд, если порог не задан. Статус degraded не открывает инцидент и не отправляет оповещения. pending — ещё не было ни одной проверки (монитор только что создан или стоит на паузе). auth_error — токен авторизации у монитора с учётными данными был отклонён; см. «Мониторинг с авторизацией».
Почему проверка не прошла
В логе проверок монитора есть колонка «Причина» — она называет конкретную причину сбоя, а под ней показан сырой технический текст ошибки. Категории: домен не резолвится (проблема DNS — имя больше никуда не указывает), соединение отклонено (на этом порту никто не слушает), соединение неожиданно закрыто, хост недоступен, TLS-сертификат истёк, TLS-сертификат не доверенный, TLS-сертификат выдан для другого домена, ошибка TLS-рукопожатия, превышено время ожидания (нет ответа за 30 секунд), слишком много редиректов, неожиданный код ответа, проверка по ключевому слову не прошла и медленнее вашего порога. У проверок, записанных до сентября 2026 года, может стоять прочерк — по сохранённым тогда данным причину определить нельзя.
Постановка монитора на паузу
Монитор на паузе полностью перестаёт проверяться, а любой открытый по нему инцидент автоматически закрывается — он не будет продолжать оповещать вас о том, что вы намеренно отключили (плановое обслуживание, вывод из эксплуатации). Возобновить проверку можно в любой момент.