Comment surveiller les tâches cron : 5 modèles avec des contrôles heartbeat

Cron excelle à lancer des choses selon un planning et est catastrophique pour vous dire quand il ne le fait pas. Une sauvegarde qui cesse de s'exécuter ne produit que rarement une erreur que vous verrez. Elle ne fait simplement plus rien, en silence, et vous le découvrez des semaines plus tard, quand vous avez besoin de la sauvegarde et qu'elle n'est pas là. C'est le problème de l'échec silencieux, et c'est précisément pour cela que chaque tâche planifiée qui compte a besoin d'un contrôle heartbeat.

Un heartbeat (ou « dead man's switch ») inverse la logique. Au lieu d'alerter quand quelque chose va mal, votre tâche pingue un point d'accès de surveillance quand tout va bien. Si le ping attendu n'arrive pas à temps, le moniteur alerte. Pas de ping, pas de nouvelles, gros problème.

Vous trouverez ci-dessous cinq modèles, du plus simple au plus robuste. Tous supposent que vous disposez d'une URL de heartbeat fournie par votre outil de surveillance.

Modèle 1 : le dead man's switch classique

La configuration la plus simple possible. Votre tâche appelle l'URL une fois terminée. Si le moniteur ne reçoit pas de message dans la fenêtre attendue, il alerte.

# Sauvegarde quotidienne à 02:30, ping une fois terminée
30 2 * * * /usr/local/bin/backup.sh && curl -fsS https://votre-moniteur/ping/abc123

Le && compte : curl ne s'exécute que si backup.sh se termine avec le code 0 (succès). Si la sauvegarde échoue, aucun ping n'est envoyé et le moniteur le détecte. Les options -fsS font que curl échoue en silence sur les erreurs HTTP, tout en montrant quand même les vrais problèmes.

Faiblesse : il confirme seulement que le script a tourné et s'est terminé avec un zéro. Si le script avale ses propres erreurs et se termine quand même avec un zéro, vous obtenez un faux « tout va bien ».

Modèle 2 : ping seulement en cas de vrai succès

Rendez le signal de succès explicite au lieu de vous appuyer sur l'enchaînement des codes de sortie dans le shell. Dans les scripts à plusieurs étapes, c'est plus clair.

#!/bin/bash
set -euo pipefail   # à la moindre erreur, échoue bruyamment
run_the_backup
verify_the_backup    # vérifie réellement que la sortie existe et a du sens
curl -fsS https://votre-moniteur/ping/abc123   # atteint seulement si tout ce qui précède a réussi

set -euo pipefail signifie que toute commande en échec interrompt le script avant le ping. L'ajout d'une vraie étape de vérification (le fichier de sauvegarde existe, il fait plus de zéro octet) ferme le trou « terminé avec un zéro, mais rien n'a été fait » du Modèle 1.

Modèle 3 : l'enveloppe de code de sortie

Quand vous ne pouvez pas modifier la tâche elle-même (binaire tiers, script d'un fournisseur), enveloppez-la. L'enveloppe signale le démarrage, lance la tâche et rapporte le code de sortie.

#!/bin/bash
URL=https://votre-moniteur/ping/abc123
curl -fsS "$URL/start"                  # signal « j'ai démarré »
/opt/vendor/report-generator            # la tâche que vous ne contrôlez pas
EXIT=$?
curl -fsS "$URL/$EXIT"                   # rapporte le code de sortie

Signaler le démarrage permet au moniteur de mesurer aussi la durée d'exécution et de repérer une tâche qui a démarré mais ne s'est jamais terminée (elle s'est figée). Rapporter le code de sortie lui permet de distinguer « s'est déroulée correctement » de « s'est déroulée et a échoué ».

Modèle 4 : ping conditionnel (pingue seulement quand le travail avait du sens)

Certaines tâches s'exécutent selon un planning mais ne font le vrai travail que parfois (un processeur de file d'attente qui trouve souvent la file vide). Vous ne voulez pas d'alerte « heartbeat manquant » quand la tâche n'a légitimement rien fait. Pinguez seulement quand le vrai travail a eu lieu, et élargissez le planning en conséquence.

#!/bin/bash
PROCESSED=$(process_queue)
if [ "$PROCESSED" -gt 0 ]; then
  curl -fsS "https://votre-moniteur/ping/abc123?count=$PROCESSED"
fi

Réglez la période attendue du moniteur sur le plus long écart réaliste entre deux vraies exécutions. Le prix à payer est la sensibilité : une fenêtre plus longue signifie une détection plus lente, ne l'utilisez donc que lorsque le travail irrégulier est vraiment attendu.

Modèle 5 : jitter et fenêtres de grâce

Les plannings réels dérivent. Une tâche réglée sur 02:00 peut démarrer à 02:00:04 à cause de la charge, et la durée d'exécution d'une tâche quotidienne fluctue. Si le moniteur attend un ping exactement à l'intervalle, un jitter normal vous fait sonner l'alarme pour rien.

La solution est une période de grâce : dites au moniteur d'attendre encore une certaine marge après l'heure attendue avant d'alerter. Une sauvegarde quotidienne qui dure habituellement 8 minutes peut utiliser une fenêtre de grâce de 20 minutes. Vous voulez aussi un certain jitter dans la planification elle-même, quand vous avez beaucoup de tâches, pour qu'elles ne sollicitent pas la même ressource à la même seconde :

# Ajoute un petit délai aléatoire (0-59 s) pour étaler les tâches de 02:00
0 2 * * * sleep $((RANDOM % 60)) && /usr/local/bin/backup.sh && curl -fsS https://votre-moniteur/ping/abc123

Les fenêtres de grâce font la différence entre un moniteur auquel vous faites confiance et un moniteur que vous mettez en sourdine après la troisième fausse alerte. Réglez la grâce pour qu'elle dépasse confortablement le pire temps d'exécution réel de la tâche, pas sa moyenne.

Aperçu rapide

Comment passer à la pratique

Commencez par le Modèle 1 sur votre tâche la plus importante dès aujourd'hui (sauvegarde, exécution de facturation, synchronisation de données). Ajoutez la vérification (Modèle 2) et la fenêtre de grâce (Modèle 5) avant de commencer à compter dessus. Pour un guide plus détaillé sur la configuration du heartbeat, consultez notre guide surveillance des tâches cron via heartbeat.

Si votre tâche communique avec un service sur un port précis, vérifiez d'abord sa joignabilité avec le vérificateur de ports gratuit. Et quand vous serez prêt à surveiller les tâches planifiées en même temps que les sites web et les API au même endroit, regardez comment fonctionne la surveillance de disponibilité d'ePulz.io - la période d'essai de 7 jours est gratuite, sans carte.