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