Pourquoi les tâches cron échouent en silence — et comment le savoir

Il existe un type de panne particulièrement pénible : la panne silencieuse. Une tâche planifiée cesse de fonctionner, rien n’alerte, et des semaines plus tard vous découvrez les dégâts — une sauvegarde vide, un cycle de facturation qui n’a jamais tourné, un index de recherche figé dans le temps. Cet article explique pourquoi cela arrive et comment l’éviter.

Cron déclenche et oublie

Le problème fondamental est qu’cron sous Unix est un lanceur, pas un superviseur. Il exécute votre commande à la minute prévue et passe à autre chose. Peu lui importe que la commande se termine par 0 ou 1, qu’elle se bloque indéfiniment ou qu’elle affiche une trace d’erreur. Il n’a aucune notion de réussite, d’échec, ou de « cela aurait dû tourner il y a une heure et ne l’a pas fait ».

Une tâche peut donc échouer de toutes les façons habituelles — une dépendance indisponible, des identifiants expirés, un disque plein, un déploiement qui a changé un chemin — et du point de vue de cron, il ne s’est rien passé.

Les trois modes d’échec que personne ne détecte

1. Elle a tourné et a échoué. Le script a démarré mais s’est terminé avec un code non nul. Cron ne le remarque pas ; au mieux, il envoie un e-mail à la boîte locale de root, que personne ne lit.
2. Elle s’est bloquée. La tâche a démarré et ne s’est jamais terminée, retenant un verrou ou fuyant de la mémoire. La prochaine exécution planifiée pourrait même ne pas démarrer.
3. Elle n’a jamais tourné. Le serveur a redémarré, la crontab a été mal modifiée, ou le fuseau horaire a changé à cause de l’heure d’été. La tâche ne se déclenche tout simplement pas — et l’absence est la chose la plus difficile à remarquer.

Les deux premiers cas exigent que la tâche signale son résultat. Le troisième ne peut pas être détecté sur la machine elle-même, car ce qui vous préviendrait est justement ce qui est cassé.

La solution : heartbeats et journaux d’exécution

Deux schémas comblent l’écart.

Les heartbeats déplacent la question « a-t-elle tourné ? » hors de la machine qui pourrait elle-même être en panne. Votre tâche envoie un ping à un service externe lorsqu’elle se termine ; si le ping n’arrive pas à l’heure prévue, le service vous alerte. Surtout, cela capture le cas « n’a jamais tourné » — le silence est le signal.

# à la fin de votre tâche
curl -fsS https://ping.steadycron.com/<votre-jeton-ping>

Les journaux d’exécution capturent le résultat de chaque exécution — statut, durée, sortie — pour que « la tâche de 3 h a-t-elle réussi, et qu’a-t-elle renvoyé ? » ait une réponse des jours plus tard.

Où se situe SteadyCron

SteadyCron fait les deux. Il peut exécuter vos tâches HTTP — avec réessais et délais d’expiration, en journalisant chaque appel — et il peut surveiller par heartbeat le cron que vous exécutez déjà — en alertant sur les exécutions manquées, échouées et bloquées via e-mail, Slack, Discord, Telegram et webhooks.

Si vous avez déjà appris l’échec d’une tâche par un client plutôt que par un tableau de bord, c’est exactement le problème pour lequel nous l’avons conçu.

Commencer gratuitement ou lire le guide de surveillance heartbeat.