Pour surveiller une tâche cron, donnez-lui un heartbeat : une URL unique que la tâche appelle chaque fois qu’elle se termine. Un service de surveillance attend cette requête à intervalle régulier. Si elle n’arrive pas à temps, parce que la tâche ne s’est pas lancée, a planté ou s’est bloquée, vous recevez une alerte. Il suffit d’une ligne de plus dans votre crontab.
Ce guide explique comment fonctionnent les heartbeats, comment en ajouter un et comment choisir les bons réglages.
Pourquoi les tâches cron ont besoin de leur propre surveillance
Cron est fiable pour lancer des commandes, et muet sur la suite. Si un script de sauvegarde échoue à 02:00, rien de visible ne casse. Le site reste en ligne et les vérifications de disponibilité restent au vert. Vous le découvrez des semaines plus tard, le jour où vous avez besoin de la sauvegarde et qu’elle n’existe pas.
Les échecs silencieux typiques :
Le serveur était en panne ou en cours de redémarrage à l’heure prévue.
La crontab a été écrasée lors d’un déploiement ou d’une migration de serveur.
La commande échoue sous cron parce que PATH ou d’autres variables d’environnement diffèrent de celles de votre shell.
Le script tourne, mais reste bloqué sur un verrou, un appel réseau ou un disque plein.
Des identifiants ont expiré : la tâche démarre puis s’arrête sur une erreur que personne ne lit.
La surveillance de disponibilité ne voit rien de tout cela, car rien de public ne casse. Un heartbeat fonctionne dans l’autre sens : au lieu que le moniteur vérifie votre tâche, c’est votre tâche qui se signale au moniteur.
Comment fonctionne un heartbeat
Vous créez un moniteur heartbeat et obtenez une URL unique.
Vous indiquez quand la tâche doit s’exécuter, sous forme d’intervalle (toutes les 24 heures, par exemple) ou avec la planification crontab de la tâche elle-même, avec une marge pour les exécutions lentes.
La tâche appelle l’URL en GET ou en POST quand elle se termine.
Si aucune requête n’arrive à temps, un incident s’ouvre et les alertes partent.
Quand le ping suivant arrive, le heartbeat se rétablit et vous recevez un avis de rétablissement.
Les moniteurs cron d’Uptimecheck fonctionnent ainsi. Ils acceptent la planification crontab dans votre fuseau horaire, reçoivent les pings de début et de fin sur un même moniteur, alertent quand une exécution dépasse sa durée maximale, et peuvent enregistrer le code de sortie et la sortie de la tâche. Les alertes partent par e-mail, Slack, Microsoft Teams, Discord, Google Chat, Mattermost, Telegram, PagerDuty, ntfy, Pushover, webhooks et notifications push sur votre téléphone, sur toutes les offres.
Ajouter un heartbeat à une crontab
Prenons une sauvegarde qui tourne chaque nuit à 02:30 :
30 2 * * * /usr/local/bin/backup.sh
Ajoutez le ping après la tâche, enchaîné avec && pour qu’il ne parte que si la sauvegarde réussit :
30 2 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 –retry 3 https://heartbeat.example.com/your-unique-id > /dev/null
Le rôle des options de curl :
-f fait échouer curl sur les erreurs HTTP au lieu de les traiter comme un succès.
-s le rend silencieux, et -S affiche tout de même les erreurs en cas de problème.
-m 10 arrête d’attendre au bout de 10 secondes, pour qu’un réseau lent ne bloque jamais la tâche.
–retry 3 réessaie en cas de brefs problèmes réseau.
Remplacez l’URL d’exemple par l’URL exacte de votre moniteur heartbeat.
Envoyer le ping depuis un script
Pour les scripts plus longs, placez le ping à la fin du script lui-même, après les étapes qui comptent :
#!/usr/bin/env bash
set -euo pipefail
pg_dump northwind > /backups/northwind-$(date +%F).sql
gzip /backups/northwind-$(date +%F).sql
curl -fsS -m 10 –retry 3 https://heartbeat.example.com/your-unique-id > /dev/null
Avec set -e, le script s’arrête à la première commande en échec : le ping n’est donc envoyé que si tout ce qui précède a fonctionné.
Autres planificateurs
Les heartbeats ne se limitent pas à cron. Tout ce qui peut envoyer une requête HTTP peut envoyer un ping : timers systemd, Planificateur de tâches Windows avec Invoke-WebRequest de PowerShell, CronJob Kubernetes, pipeline de CI ou fonction planifiée dans votre application.
Choisir l’intervalle
L’intervalle doit correspondre à la planification : 24 heures pour une tâche nocturne, 1 heure pour une tâche horaire. Prévoyez une marge pour les variations normales de durée. Si une sauvegarde prend habituellement 20 minutes mais parfois 50, une heure de marge supplémentaire évite les fausses alertes sans masquer longtemps un vrai échec.
Commencez large, observez pendant une semaine ou deux la durée réelle des exécutions, puis resserrez. Si votre moniteur accepte directement l’expression crontab, comme celui d’Uptimecheck, collez la planification et choisissez le fuseau horaire du serveur. Les heures attendues suivent alors exactement la planification, et la marge devient un délai de grâce.
Les heartbeats face aux autres approches
Il existe d’autres façons de surveiller les tâches planifiées, chacune avec ses lacunes :
Les e-mails de cron. Cron peut envoyer par e-mail la sortie d’une commande, mais seulement quand la tâche s’exécute et produit une sortie. Si la tâche ne démarre jamais, aucun e-mail. Et la plupart de ces e-mails ne sont de toute façon jamais lus.
La surveillance des logs. Utile pour trouver des erreurs, mais une tâche qui ne s’est jamais exécutée n’écrit aucune ligne de log à rechercher.
La vérification des résultats. Certaines équipes vérifient qu’un fichier de sauvegarde existe ou qu’une table a été mise à jour. Cela fonctionne, mais exige une vérification sur mesure pour chaque tâche.
Un heartbeat fonctionne de la même manière pour toutes les tâches et détecte le cas que les autres ratent : la tâche qui ne s’est pas exécutée du tout.
Tâches de longue durée
Pour les tâches longues, comme de grosses sauvegardes ou des migrations de données, envoyez un ping au début en plus de celui de la fin. Si le ping de début arrive mais pas celui de fin, la tâche s’est bloquée ou a planté en cours de route. Vous savez où chercher avant même d’ouvrir un fichier de log.
Dans Uptimecheck, les deux pings vont au même moniteur : appelez l’URL suivie de /start au démarrage de la tâche, et l’URL simple à la fin. Le temps écoulé entre les deux est enregistré comme durée d’exécution et, si vous définissez une durée maximale, vous êtes alerté quand une exécution dure plus longtemps.
Quelles tâches équiper d’un heartbeat
Toutes les tâches n’en ont pas besoin. Donnez la priorité à celles dont vous ne remarqueriez l’échec que plus tard :
Sauvegardes de bases de données et de fichiers.
Imports et exports de données, comme les flux produits ou les synchronisations comptables.
Facturation, renouvellements et tâches de paiement.
Tâches de renouvellement de certificats.
Nettoyages qui empêchent un disque de se remplir.
Génération de rapports dont d’autres dépendent.
Donnez à chaque tâche son propre heartbeat. Un heartbeat partagé vous dit que quelque chose ne s’est pas exécuté, mais pas quoi.
Diagnostiquer un heartbeat manqué
Quand une alerte heartbeat arrive :
Vérifiez si cron a lancé la tâche. Consultez le log de cron ou du système.
Lancez la commande à la main avec le même utilisateur que cron, et lisez la sortie.
Vérifiez l’environnement. Utilisez des chemins absolus, ou définissez PATH en haut de la crontab.
Vérifiez les ressources. Un disque plein ou une mémoire saturée bloque bien des tâches. La surveillance de serveur montre le disque, la RAM et la charge au moment de l’échec.
Vérifiez le réseau sortant. Une modification du pare-feu peut bloquer le ping même quand la tâche fonctionne. Si la tâche s’est exécutée mais que le ping a échoué, l’erreur de curl apparaît dans la sortie de la tâche.
Redirigez la sortie de la tâche vers un fichier de log, pour avoir toujours quelque chose à lire :
30 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1 && curl -fsS -m 10 https://heartbeat.example.com/your-unique-id > /dev/null
Vous pouvez aussi envoyer le résultat avec le ping. Dans Uptimecheck, terminer l’URL par le code de sortie (/0 signifie succès, toute autre valeur un échec) indique comment la tâche s’est terminée, et le corps d’une requête POST est conservé comme sortie de la tâche et affiché avec l’alerte. Cette ligne envoie un ping au début, exécute la tâche, puis transmet son code de sortie et sa sortie :
30 2 * * * curl -fsS -m 10 –retry 3 -o /dev/null https://heartbeat.example.com/your-unique-id/start; /usr/local/bin/backup.sh > /tmp/backup.log 2>&1; curl -fsS -m 10 –retry 3 –data-binary @/tmp/backup.log -o /dev/null https://heartbeat.example.com/your-unique-id/$?
Checklist de surveillance des tâches cron
Listez les tâches planifiées qui comptent, sur chaque serveur.
Créez un heartbeat par tâche.
Envoyez le ping une fois le travail réussi, enchaîné avec && ou à la fin d’un script set -e.
Réglez l’intervalle sur la planification, avec une marge pour les exécutions lentes.
Journalisez la sortie des tâches dans un fichier.
Envoyez les alertes vers un canal que quelqu’un lit, y compris la nuit pour les tâches critiques.
Relisez l’historique des heartbeats après les déploiements et les migrations de serveur.
En résumé
Cron ne vous prévient pas quand une tâche échoue. Un heartbeat, si. Une ligne curl par tâche transforme les échecs silencieux en alertes, et l’historique vous montre exactement quand chaque tâche s’est exécutée pour la dernière fois.
Les heartbeats sont inclus dans toutes les offres Uptimecheck, avec la surveillance de disponibilité, SSL, domaine, DNS et serveur. Essayez gratuitement pendant 14 jours, sans carte bancaire.