Monitoring des cron jobs et workers en arrière-plan via heartbeat

En bref : Le monitoring HTTP classique ne détectera pas que votre cron nocturne envoyant des factures ou synchronisant des données est tombé. Le pattern heartbeat inverse le sens de communication - le cron rapporte au monitoring, et s'il n'appelle pas à l'heure prévue, vous recevez une alerte.

Le problème : tâches en arrière-plan sans endpoint HTTP

Un backend typique a des chemins :

• Requêtes web (HTTP/HTTPS vers le serveur) - vous monitorez avec un uptime check.
• Cron jobs (backup quotidien, facturation mensuelle, sync horaire) - n'ont pas d'endpoint HTTP, le monitoring externe ne les voit pas.
• Workers (Celery, BullMQ, Sidekiq) consommant une queue - aussi sans HTTP.

Si le cron tombe (vous changez crontab et faites une faute, le serveur n'a pas de disque, une variable d'environnement manque, un upgrade de dépendance a cassé l'import), personne ne vous avertit - jusqu'à ce que lundi matin vous remarquiez que les factures n'ont pas été envoyées le week-end.

Pattern heartbeat : le cron ping le monitoring

Le principe est inverse du monitoring normal :

1. Dans le service de monitoring vous créez un monitor heartbeat avec un intervalle attendu (par ex. « toutes les 60 minutes »).
2. Vous recevez une URL heartbeat unique : https://epulz.io/heartbeat/abc123xyz.
3. Dans votre cron job à la fin d'un run réussi vous appelez cette URL (HTTP GET ou POST).
4. Si le ping n'arrive pas à l'heure attendue (+ période de grace), le monitoring vous alerte.

Exemple pratique : bash cron

# /etc/crontab
0 3 * * * www-data /usr/local/bin/backup.sh && curl -fsS -m 10 \
  https://epulz.io/heartbeat/abc123xyz > /dev/null

La clé est le && - le heartbeat n'est envoyé que si backup.sh se termine avec exit code 0. Si le script échoue, le ping ne viendra pas, et dans l'heure vous recevez une alerte.

Astuce : Pour une couverture plus rigoureuse ajoutez aussi un « start » heartbeat :

curl -fsS -m 10 https://epulz.io/heartbeat/abc123xyz/start > /dev/null
/usr/local/bin/backup.sh
EXIT=$?
curl -fsS -m 10 "https://epulz.io/heartbeat/abc123xyz?exit=$EXIT" > /dev/null

Le monitoring distingue alors « démarré et non terminé » (script gelé) de « pas démarré du tout » (le cron job ne s'est pas exécuté).

Python : requests + try/except

import os, requests
HEARTBEAT_URL = os.environ["HEARTBEAT_URL"]

def sync_data():
    # votre logique
    pass

try:
    sync_data()
    requests.get(HEARTBEAT_URL, timeout=10)
except Exception as e:
    # Le heartbeat n'est pas envoyé - le monitoring vous alertera
    raise

Node.js : async / await

const HEARTBEAT_URL = process.env.HEARTBEAT_URL;

async function nightlyJob() {
  await processInvoices();
  await fetch(HEARTBEAT_URL, { signal: AbortSignal.timeout(10000) });
}

nightlyJob().catch(err => {
  console.error(err);
  process.exit(1);
});

Période de grace : combien de temps donner avant l'alerte

Le monitor heartbeat a besoin de tolérance - le cron tourne parfois plus longtemps que d'habitude, le réseau a de la latence, la sync NTP peut être légèrement décalée. La période de grace est le temps après l'intervalle attendu pendant lequel le monitoring attend encore.

Valeurs pratiques :

• Hourly cron : intervalle 60 min + grace 10 min
• Daily backup (en moyenne 20 min) : intervalle 1440 min + grace 60 min
• Weekly report : intervalle 10080 min + grace 360 min (6 h)

Grace trop serré = alertes faux-positifs. Trop lâche = avertissement retardé quand ça tombe vraiment.

Où le pattern heartbeat aide le plus

• Backups DB nocturnes
• Synchronisation avec API externes (CRM, accounting, payment)
• Calculs de rapports
• Tâches cleanup (suppression de vieilles sessions, logs, fichiers temporaires)
• Cycle healthcheck de workers à long terme
• Emails planifiés, newsletters, facturation

Conclusion

Les tâches en arrière-plan sont souvent plus critiques que le web lui-même, mais restent un angle mort du monitoring. Le pattern heartbeat demande 5 minutes d'implémentation (ajouter curl à la fin de la ligne cron) et fournit la même tranquillité d'esprit que le monitoring uptime pour le frontend.

Commencez à monitorer les cron jobs

ePulz.io supporte les heartbeat checks avec période de grace configurable. 7 jours gratuits.

Lancer le monitoring →