Pourquoi vos tâches cron échouent en silence (et comment les surveiller)

Le problème avec cron

Cron est fiable d’une certaine manière : il exécutera votre commande selon le planning. Il n’est pas fiable d’une autre manière, plus importante : il ne vous dit pas quand votre commande échoue.

Votre serveur fonctionne. Le démon cron tourne. La planification se déclenche à l’heure. Mais le script que vous avez ciblé se termine avec un statut différent de zéro, dépasse un délai ou manque de mémoire. Personne ne le sait. Le rôle de cron est de démarrer le processus, pas de vérifier qu’il a réussi.

Ce n’est pas un bug de cron. C’est ainsi que cron a été conçu. Cron est antérieur au web. Il a été construit à une époque où les tâches écrivaient dans des fichiers journaux et où un humain les vérifiait périodiquement. Ce modèle ne s’adapte pas à l’infrastructure moderne où un seul développeur gère des dizaines de tâches planifiées sur plusieurs serveurs.

Ce que coûtent les échecs silencieux de cron

Un échec silencieux de sauvegarde signifie que vous le découvrez au moment où vous avez besoin de la sauvegarde. Peut-être trois semaines plus tard, après un incident de corruption de base de données. L’écart entre le moment où la sauvegarde a cessé de fonctionner et le moment où vous en aviez besoin représente des données irrécupérables.

Un échec silencieux de file d’attente d’e-mails signifie que les clients cessent de recevoir des notifications. Réinitialisations de mot de passe, confirmations de commande, reçus de facturation. Personne ne se plaint au début car personne ne sait ce qui manque. Au moment où vous le remarquez, vous avez des milliers d’e-mails non distribués et des utilisateurs confus.

Un échec silencieux d’exportation de données signifie que vos analyses sont fausses. Vos tableaux de bord montrent des tendances basées sur des données obsolètes. Vous prenez des décisions sur des informations incomplètes. L’erreur s’aggrave plus elle reste non détectée.

Pourquoi la surveillance de disponibilité ne détecte pas cela

Votre moniteur de disponibilité indique que votre serveur est en ligne. Votre API renvoie 200. Votre tableau de bord se charge. Tout va bien selon votre tableau de bord de surveillance.

Mais aucune de ces vérifications ne vous dit si la sauvegarde de la nuit dernière s’est terminée. Elles ne savent pas si votre rapprochement de facturation a été exécuté. Elles ne savent pas si le pipeline de données qui alimente vos analyses a terminé.

La surveillance de disponibilité répond à la question : « Puis-je atteindre ce point d’accès ? » La surveillance heartbeat répond à : « Cette tâche s’est-elle exécutée ? » Ce sont des questions complémentaires. Vous avez besoin des deux.

Comment fonctionne la surveillance heartbeat

La surveillance heartbeat est simple. Chaque tâche planifiée reçoit une URL unique avec un jeton secret. À la fin de votre tâche, ajoutez une seule ligne qui envoie un ping à cette URL :

curl -s https://pingwatchdog.com/api/v1/heartbeat/hw_YOURTOKEN

Si le ping arrive dans la fenêtre attendue, la vérification heartbeat est réussie. Si la fenêtre se ferme sans ping, le moniteur déclenche une alerte.

Vous configurez l’intervalle attendu. Si votre sauvegarde s’exécute toutes les 6 heures, réglez l’intervalle sur 6 heures. Ajoutez une période de grâce si la durée de la tâche varie. Une période de grâce de 10 minutes signifie que le moniteur n’alerte que si le ping a 10 minutes de retard.

C’est toute la configuration. Une URL. Une commande curl. Zéro fichier de configuration.

Mise en place concrète

Voici une entrée cron pour une sauvegarde nocturne de base de données :

0 2 * * * /usr/local/bin/backup-db.sh && curl -s https://pingwatchdog.com/api/v1/heartbeat/hw_YOURTOKEN

Le && est important. Il signifie : « Exécute curl uniquement si le script de sauvegarde se termine avec le statut 0 (succès). » Si la sauvegarde échoue, curl ne s’exécute jamais. Aucun ping n’arrive. Vous recevez une alerte.

Si vous voulez surveiller que le script s’est exécuté du tout (même en cas d’échec), utilisez ; au lieu de &&, et ajoutez une gestion d’erreur dans le script pour signaler le statut. Mais pour la plupart des cas d’usage, && est ce que vous voulez. Vous vous souciez du succès, pas seulement de l’exécution.

Que surveiller avec les heartbeats

Commencez par les tâches qui feraient le plus mal si elles échouaient silencieusement :

Sauvegardes de base de données : C’est le cas d’usage le plus courant et celui dont le coût d’échec est le plus élevé. Une sauvegarde dont vous ignorez l’absence est pire que pas de sauvegarde du tout.

Files d’attente de distribution d’e-mails : Si vos e-mails transactionnels ou marketing cessent d’être envoyés, vous voulez le savoir en quelques minutes, pas en quelques heures.

Facturation et génération de factures : Une facturation échouée signifie une perte de revenus. Un heartbeat sur votre tâche de facturation détecte cela avant la fin du mois.

Synchronisations et exportations de données : Si votre pipeline d’analyse ou la synchronisation de votre entrepôt de données échoue, vos rapports sont faux. Un heartbeat vous informe dans l’intervalle attendu.

Renouvellement de certificats : Si vous utilisez certbot ou des outils similaires avec renouvellement automatique, ajoutez un heartbeat. L’expiration des certificats est l’une des causes de panne les plus évitables.

Rotation et nettoyage des journaux : Si la rotation des journaux échoue, votre disque se remplit. Votre serveur tombe en panne. Un heartbeat détecte l’échec de rotation avant que le disque ne soit plein.

Surveillance heartbeat vs. services de surveillance cron

Des outils comme Healthchecks.io et Cronitor se concentrent exclusivement sur la surveillance des tâches cron et planifiées. Ils le font bien. Certains ajoutent des fonctionnalités comme le suivi de la durée des tâches et les tendances de performance.

PingWatchdog inclut la surveillance heartbeat aux côtés de la surveillance de disponibilité et de la surveillance SSL sur une seule plateforme. Vous n’avez pas besoin d’un outil séparé pour les tâches cron. Vous surveillez vos sites web, API, certificats SSL et tâches planifiées depuis un seul tableau de bord avec un seul pipeline d’alertes.

C’est important car la même équipe qui surveille la disponibilité gère généralement les tâches cron. Consolider les outils signifie moins de tableaux de bord à vérifier, moins de canaux d’alerte à configurer et moins d’abonnements à gérer.

Comparez PingWatchdog avec Healthchecks.io pour voir comment notre surveillance heartbeat se positionne face à la surveillance de disponibilité et aux pages de statut.

Surveillance cron dans les conteneurs et Kubernetes

Si vous exécutez des tâches cron dans des conteneurs Docker ou des CronJobs Kubernetes, le même schéma heartbeat fonctionne. Ajoutez une commande curl à la fin du point d’entrée de votre conteneur ou de la commande de votre CronJob.

Pour Kubernetes :

apiVersion: batch/v1
kind: CronJob
metadata:
  name: db-backup
spec:
  schedule: "0 2 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: backup
            image: your-backup-image
            command:
            - /bin/sh
            - -c
            - "/backup.sh && curl -s https://pingwatchdog.com/api/v1/heartbeat/hw_YOURTOKEN"
          restartPolicy: OnFailure

Le même principe s’applique aux événements planifiés AWS Lambda, Google Cloud Scheduler, aux timers systemd ou à tout autre planificateur. Si votre tâche peut faire une requête HTTP, elle peut envoyer un heartbeat.

Démarrez

PingWatchdog inclut la surveillance heartbeat dans chaque plan. Le plan gratuit vous donne 3 moniteurs heartbeat. Les plans payants vont jusqu’à 25.

En savoir plus sur les fonctionnalités de surveillance heartbeat ou configurez votre premier moniteur.