Surveiller un cron Linux

Le problème classique avec cron : quand un job échoue ou ne se lance plus, personne n'est prévenu. Le mail local de cron finit dans/var/mail que personne ne lit. Résultat : un backup silencieusement cassé depuis 3 semaines, qu'on découvre le jour où on en a besoin.

Pourquoi les crons échouent silencieusement

• Le serveur a redémarré et crond n'est pas reparti.
• Le PATH du cron diffère du shell interactif → commande introuvable.
• Le disque est plein, un verrou (flock) bloque l'exécution.
• Le script plante mais renvoie un code 0, donc « tout va bien ».

La solution : un dead man's switch

Plutôt que de surveiller le serveur, on demande au cron de signaler qu'il a tourné. S'il ne signale rien à l'heure prévue, c'est lui-même le problème. Crée un check sur Cron-Ping, récupère ton URL, et ajoute un curl :

# avant : on ne sait jamais si ça tourne
0 2 * * * /opt/backup.sh

# après : ping uniquement si le script réussit
0 2 * * * /opt/backup.sh && curl -fsS https://cron-ping.com/p/<token>

Distinguer succès et échec

0 2 * * * /opt/backup.sh && curl -fsS https://cron-ping.com/p/<token> || curl -fsS https://cron-ping.com/p/<token>/fail

Si backup.sh échoue, on appelle /fail et tu reçois une alerte immédiate, sans attendre le délai de grâce.

Vérifier que cron tourne bien

systemctl status cron      # Debian/Ubuntu
systemctl status crond     # RHEL/CentOS
grep CRON /var/log/syslog  # voir les exécutions