Що таке heartbeat-моніторинг / cron-job?

Зворотній моніторинг — твоє заплановане завдання пінгує наш URL при успішному запуску. Якщо ми не почуємо його у відведений час — надсилаємо тривогу. Це вирішує проблему «тихих» збоїв: зламаний cron-job не видає помилки і не запускає класичний тривожний uptime-алерт.

Як інтегрувати heartbeat-URL у мій cron?

Додай curl -fsS <heartbeat_url> у кінець команди cron. Якщо команда перед цим не спрацювала — curl не виконається і heartbeat буде пропущено. Або пінгуй на початку і в кінці різними шляхами — це окремі сигнали "started" і "completed".

Який запас часу (grace period) варто встановити?

Десь 2-3x від типової тривалості виконання завдання. Якщо твій щоденний backup триває 30 хв, став запас у 90 хв — це враховує затримки без помилкових тривог. Для завдань із непередбачуваною тривалістю постав запас з запасом і користуйся дашбордом для пошуку аутлайєрів.

Чи можна моніторити cron job'и, які запускаються щогодини?

Так — інтервал став відповідний (наприклад, 60 хвилин з запасом у 15 хв). Монітор чекає на ping щонайменше раз на 75 хв. Якщо твоє завдання частіше (кожні 5 хв) — heartbeat-URL теж це підтримує, просто підбирай інтервал відповідно.

Чи працює heartbeat-моніторинг для AWS Lambda чи serverless?

Так. Додай outgoing HTTP-виклик на heartbeat-URL наприкінці Lambda-функції. Монітор відноситься до цього так само, як до cron-heartbeat — ті самі алерти, той самий “grace period”. Особливо корисно для запланованих Lambda, де CloudWatch не бачить «тихих» збоїв виконання.

Моніторинг cron — Heartbeats і Dead-Man

Дізнайтесь відразу, коли заплановані завдання припинили виконання. Резервні копії, чергові робітники, ETL-завдання, годинна синхронізація — все під наглядом.

Проблема із запланованими завданнями

Жорстока риса cron-процесів у тому, що якщо вони падають, ти про це нічого не дізнаєшся. Вебзастосунок і далі обробляє запити, головна сторінка виглядає нормально, моніторинг показує зелений — але десь на сервері нічний backup не запускали вже два тижні. Queue worker впав після деплою, і старі job'и накопичуються. Синхронізація щогодини тихо втрачає рядки через проблему з правами. Дізнаєшся ти лише тоді, коли щось далі по ланцюгу нарешті впаде — зазвичай саме тоді, коли це потрібно найбільше. Data team хоче експорт, підтримка — чергу листів, ops — backup. Тоді вже надто пізно.

Стандартний моніторинг доступності це не зловить, бо тут нема що пінгувати. Cron не відкриває HTTP endpoint, не слухає порт, не запускає сервер. Він стартує, завершується, і так знов. Якщо перестає працювати — жодного сигналу про його відсутність, поки не почнеш шукати вручну.

Зворотний підхід: heartbeat-моніторинг

Heartbeat-моніторинг (його ще називають «dead man’s switch» або «моніторинг cron-процесів») перевертає все навпаки. Замість того, щоб ми перевіряли твою службу, твоя служба відмічається у нас. Треба додати одну стрічку до cron — curl на унікальний URL, який ми генеруємо — і цей URL зберігатиме мітку часу кожного разу, коли отримує ping. Ми стежимо за відсутністю ping'ів. Якщо URL не відкрили у потрібному інтервалі (плюс запас), це вважається пропущеним запуском і надсилається сповіщення.

Модель проста, надійна й мовонезалежна. Все, що вміє робити HTTP-запит, — інтегрується. Bash — через curl, Python — через requests, Node — через fetch, PHP — через curl_init, Task Scheduler у Windows — через Invoke-WebRequest, GitHub Actions, Kubernetes CronJobs, Lambda scheduled events — будь-що. Без SDK, агентів та демонів для встановлення.

Як налаштувати

У DiagnoSEO Uptime Monitoring натисни «Додати монітор», вибери тип «Heartbeat / cron». Інструмент згенерує унікальний URL із токеном — типу https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9. Вкажи очікуваний інтервал (як часто має діяти job, у хвилинах) та запас (наскільки затримка ще допустима, поки не почнуться тривоги). Збережи.

Тепер зміни cron так, щоб він пінгував URL після кожного успішного запуску. Три варіанти залежно від середовища:

# Bash cron - ping тільки при успіху
0 3 * * * /usr/bin/backup.sh && curl -fsS https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9 > /dev/null

# Або якщо частковий успіх прийнятний
0 3 * * * /usr/bin/backup.sh; curl -fsS https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9 > /dev/null

# Python
import requests
def main():
    do_the_work()
    requests.get('https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9', timeout=5)

# GitHub Actions
- name: Notify heartbeat
  if: success()
  run: curl -fsS https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9

Відтепер кожен успішний запуск надсилає нам ping, а ми фіксуємо timestamp. Якщо не побачимо ping у межах інтервал + запас хвилин — відкривається інцидент і летять повідомлення на всі увімкнені канали: Email, Telegram, Slack, Discord, SMS.

Вибір інтервалу й запасу

Інтервал має відповідати графіку job'у. Нічний backup о 3:00 — інтервал 1440 хв (24 год). Синхронізація щогодини — 60. Worker, який опитує що 5 хв — 5 хв.

Запас поглинає природний jitter. Cron'и не стартують буквально до наносекунди — вони стають у чергу, чекають завершення попереднього запуску, роблять back-off при коротких помилках. 24-годинний job із годинним запасом дає комфортний буфер без затримки тривог. 5-хвилинний worker з 2-хвилинним запасом швидко ловить справжні збої без false positive через 30-секундний “глік”. Загалом: став запас у межах 10-50% інтервалу, залежно від того, наскільки job «шарпається».

Шаблони, які ми радимо

Ping тільки при успіху. Використовуй && у bash — провалений запуск не пінгує. Ми визначимо відсутність ping і надішлемо сповіщення.
Ping після кожної ітерації циклу. Для тривалих workers роби ping всередині циклу після кожної вдалої одиниці роботи, а не лише у кінці. Це допомагає виявити «зависання» worker'а під час запуску.
Один heartbeat на логічний job, а не на скрипт. Якщо три скрипти разом — це один нічний pipeline, пінгуй лише раз наприкінці ланцюга. Це дає чіткий сигнал: “pipline живий”.
Комбінуй із логами. Heartbeat означає, що job стартував. Логи застосунку показують, що саме виконалось. Разом — повна картина.

Що відбувається, якщо heartbeat зникне

Інцидент відкривається одразу після спливу deadline. На дашборді монітор підсвічується червоним із помилкою “Немає heartbeat вже X хвилин”. Сповіщення надсилаються на всі твої канали. Коли свіжий heartbeat з’явиться, монітор автоматично повертається у up — позначається як up, інцидент закривається, і (якщо recovery-алерти увімкнено) ти отримуєш повідомлення “знову online”.

Все це працює так само, як і з іншими моніторами — heatmap, відсоток uptime, історія, теги, пошук, експорт. З погляду дашборду heartbeat-монітор — це просто ще один рядок, який можна сортувати та фільтрувати нарівні із HTTP, ping, port і API.

Чекліст

Додай монітор → тип Heartbeat → скопіюй згенерований URL → додай до cron / worker / scheduler → вкажи інтервал та запас → збережи → готово. Тепер ти дізнаєшся за секунду, якщо заплановане завдання зупиниться — що у довгостроковій перспективі є одним із найважливіших рішень для моніторингу, яке ти можеш прийняти.

Часті питання

Що таке heartbeat-моніторинг / cron-job?
Зворотній моніторинг — твоє заплановане завдання пінгує наш URL при успішному запуску. Якщо ми не почуємо його у відведений час — надсилаємо тривогу. Це вирішує проблему «тихих» збоїв: зламаний cron-job не видає помилки і не запускає класичний тривожний uptime-алерт.
Як інтегрувати heartbeat-URL у мій cron?
Додай curl -fsS <heartbeat_url> у кінець команди cron. Якщо команда перед цим не спрацювала — curl не виконається і heartbeat буде пропущено. Або пінгуй на початку і в кінці різними шляхами — це окремі сигнали “started” і “completed”.
Який запас часу (grace period) варто встановити?
Десь 2-3x від типової тривалості виконання завдання. Якщо твій щоденний backup триває 30 хв, став запас у 90 хв — це враховує затримки без помилкових тривог. Для завдань із непередбачуваною тривалістю постав запас з запасом і користуйся дашбордом для пошуку аутлайєрів.
Чи можна моніторити cron job'и, які запускаються щогодини?
Так — інтервал став відповідний (наприклад, 60 хвилин з запасом у 15 хв). Монітор чекає на ping щонайменше раз на 75 хв. Якщо твоє завдання частіше (кожні 5 хв) — heartbeat-URL теж це підтримує, просто підбирай інтервал відповідно.
Чи працює heartbeat-моніторинг для AWS Lambda чи serverless?
Так. Додай outgoing HTTP-виклик на heartbeat-URL наприкінці Lambda-функції. Монітор відноситься до цього так само, як до cron-heartbeat — ті самі алерти, той самий “grace period”. Особливо корисно для запланованих Lambda, де CloudWatch не бачить «тихих» збоїв виконання.

Моніторинг cron-завдань