Monitorizare cron: află când un job nu mai rulează

Un cron job care eșuează poate să-ți spună asta: ghidul pentru cron îți trimite o notificare când un job se termină cu eroare. Un job care nu mai rulează deloc nu poate. Linia din crontab s-a pierdut la mutarea pe alt server, mașina e oprită, daemonul cron nu mai merge sau jobul s-a blocat și nu se mai termină. Nimic nu eșuează, deci nu se trimite nimic, iar tu afli abia în ziua în care ai nevoie de backupul de azi-noapte.

Un monitor cron (în engleză, heartbeat) funcționează invers, motiv pentru care i se mai spune și „dead man’s switch”. Jobul apelează un URL de fiecare dată când rulează. Honk știe cât de des să se aștepte la apel, iar când acesta nu vine, deschide o problemă și te anunță pe iPhone, pe Apple Watch sau în browser. Următorul apel o închide.

Cum funcționează un monitor cron

• Alegi un interval: cât de des ar trebui să vină semnalul, de la 1 minut la 1 săptămână.
• Și o toleranță: cu cât poate veni mai târziu semnalul înainte ca Honk să-l considere întârziat; implicit, 5 minute. Termenul e ultimul semnal plus intervalul plus toleranța.
• Fiecare monitor are un URL secret, https://honk-honk.app/hb/…. O cerere GET, POST sau HEAD către el e un semnal, fără cheie și fără antete.
• Când trece termenul, Honk deschide o problemă în proiect, un Claxon lung dacă nu alegi alt nivel. Arată așa: „Backup de noapte întârzie”, cu textul „Niciun semnal din 2026-10-14 03:12 UTC. Așteptat la fiecare 1 z (+5 min toleranță).” Honk verifică cel puțin o dată pe minut.
• O întrerupere, o singură problemă. Cât timp jobul tace, Honk nu mai adaugă nimic: nicio notificare nouă în fiecare minut.
• Următorul semnal o închide cu o revenire, „Backup de noapte și-a revenit”, trimisă ca orice altă notificare.

Problema e un eveniment Honk obișnuit, în grupul heartbeat/<slug>, așa că orele de liniște, punerea pe silențios, activitățile live și regulile tale se aplică și ei, ca oricărui alt mesaj. Un monitor nou așteaptă primul semnal și nu poate întârzia înainte de el.

Înainte să începi

• Un cont Honk și un proiect. Deocamdată, Honk e disponibil doar pe bază de invitație; dacă nu ai cont, cere acces.
• Dreptul de a administra proiectul. Proprietarii și administratorii spațiului de lucru îl au.
• Loc pentru încă un monitor cron: un spațiu de lucru poate avea 2 pe planul Free, 20 pe Pro și 100 pe Team (planuri).
• curl pe mașina care rulează jobul. Îl găsești pe aproape orice server.

1. Creează monitorul

În aplicația web, deschide proiectul, apoi Conexiuni și alege Monitor nou:

• Nume: ce va apărea în notificare, de exemplu „Backup de noapte”.
• Așteaptă un semnal la fiecare: 5 minute, 15 minute, 1 oră, 1 zi, 1 săptămână sau, cu Personalizat, câte minute vrei tu.
• Toleranță: fără, 1, 5 sau 15 minute ori 1 oră.
• Nivel când întârzie: implicit un Claxon lung; pentru joburile cele mai importante, un Claxon continuu.

Salvează, apoi deschide Configurează și copiază URL-ul de la URL de semnal. Oricine are URL-ul poate trimite semnale, așa că păstrează-l ca pe o parolă. Dacă ajunge unde nu trebuie, URL nou îl înlocuiește, iar cel vechi nu mai funcționează din acel moment.

2. Trimite un semnal după fiecare rulare

Adaugă apelul după job, cu &&, ca semnalul să plece doar după o rulare reușită:

0 3 * * * pg_dump -f /backup/app.sql app && curl -fsS -m 10 --retry 3 https://honk-honk.app/hb/… > /dev/null

-fsS ține curl în liniște dacă nu apare nicio eroare, -m 10 renunță după 10 secunde, iar --retry 3 trece peste o scurtă problemă de rețea. Când jobul eșuează, nu pleacă niciun semnal, iar Honk te anunță după ce expiră toleranța.

Termenul se socotește de la ultimul semnal, deci toleranța trebuie să acopere doar cât variază durata jobului. Dacă backupul durează uneori cu 20 de minute mai mult decât de obicei, dă-i cel puțin atât.

3. Raportează imediat un eșec

Pentru un job de noapte, e în regulă să aștepți termenul. Ca să afli de un eșec chiar când se produce, apelează URL-ul cu /fail atunci când jobul eșuează. Textul trimis în corpul cererii, de cel mult 1 KiB, devine mesajul:

0 3 * * * pg_dump -f /backup/app.sql app && curl -fsS -m 10 --retry 3 https://honk-honk.app/hb/… > /dev/null || curl -fsS -m 10 --retry 3 --data-raw "pg_dump failed on $(hostname)" https://honk-honk.app/hb/…/fail > /dev/null

Honk deschide problema pe loc: „Backup de noapte a raportat o eroare”. Următorul semnal reușit o închide, ca mai sus.

Dacă jobul își raportează deja eșecurile cu wrapperul honk-cron din ghidul pentru cron, păstrează-l și lasă monitorul să urmărească doar dacă jobul rulează. Trimite semnal după fiecare rulare, reușită sau nu, cu ; în loc de &&:

0 3 * * * /usr/local/bin/honk-cron db/backup pg_dump -f /backup/app.sql app; curl -fsS -m 10 --retry 3 https://honk-honk.app/hb/… > /dev/null

Wrapperul îți spune că jobul a eșuat și ce a afișat. Monitorul îți spune că nu a rulat deloc.

Workeri, aplicații și systemd

Orice poate face o cerere HTTP poate trimite semnale: un worker de cozi după fiecare lot, un script în orice limbaj sau un serviciu systemd. Panoul Configurează din aplicația web are linii gata făcute pentru crontab și pentru OnSuccess= și OnFailure= din systemd. Honk ia în calcul cel mult un semnal la 10 secunde; apelurile în plus primesc răspuns, dar sunt ignorate.

Codul care are deja o cheie API poate folosi API-ul în locul URL-ului. Monitorul se creează la primul apel, așa că un worker și-l poate configura singur:

curl -fsS -m 10 --retry 3 https://honk-honk.app/v1/heartbeats/check-in \
  -H "Authorization: Bearer $HONK_KEY" \
  -H "Content-Type: application/json" \
  -d '{"slug":"queue-worker","name":"Queue worker","interval_seconds":300,"grace_seconds":60}'

slug identifică monitorul în proiectul cheii. Apelurile următoare îi pot schimba numele, intervalul și toleranța; nivelul și punerea pe pauză rămân în aplicația web. Ca să raportezi un eșec, trimite "status":"fail" împreună cu un message.

Weekenduri, mentenanță și pauze

Honk așteaptă semnalul la un interval fix și nu citește expresii cron. Pentru un job care rulează doar în zilele lucrătoare, fie setezi intervalul la cel mai lung timp dintre două rulări (3 zile, de vineri până luni), fie adaugi în crontab o linie care trimite semnal sâmbăta și duminica.

Înainte de o lucrare de mentenanță, apasă Pune pe pauză. Un monitor pus pe pauză nu e urmărit, iar punerea pe pauză închide o problemă deschisă. Reia pornește din nou cronometrul din acel moment. Și ștergerea unui monitor îi închide problema deschisă.

Monitoare cron și alerte de eșec

Răspund la două întrebări diferite, iar un job important le merită pe amândouă:

• Ghidul pentru cron îți spune că jobul a rulat și a eșuat, cu codul de ieșire și ce a afișat.
• Un monitor cron îți spune că jobul nu a rulat sau nu s-a mai terminat, și când a dat ultima dată semn.

Dacă ai folosit Healthchecks.io

E aceeași idee: un URL pentru fiecare job, o perioadă și o toleranță. Healthchecks.io poate urmări și expresii cron sau programări systemd OnCalendar= și e open source, deci îl poți găzdui chiar tu. Honk nu are expresii cron și nici o versiune pe care s-o găzduiești singur. În schimb, un job care tace ajunge în același inbox, cu aceleași reguli de notificare, ca tot ce mai rulezi: o singură notificare pentru fiecare întrerupere, o revenire când jobul rulează din nou, ore de liniște, activități live și Apple Watch.