Lundi matin, vous ouvrez votre ordinateur et vous réalisez que la tâche planifiée de la nuit dernière ne s’est jamais exécutée — et qu’elle est morte en silence depuis trois jours. hermes cron list affiche toujours la tâche, hermes cron status ne signale aucune erreur, mais aucune sortie, aucun message, aucun log ne vous dit ce qui s’est mal passé. Ce genre de panne silencieuse est pire qu’une erreur : la tâche « a l’air saine » alors qu’elle est en réalité morte. La nouvelle commande hermes cron doctor, fusionnée le 31 août, existe précisément pour ce scénario : une commande en lecture seule qui inspecte toute votre flotte cron de bout en bout, vous indique explicitement ce qui ne va pas et exploite son code de sortie pour que vous puissiez la brancher sur des alertes automatiques.

Pourquoi tout « a l’air normal » alors que rien ne s’exécute

Cette commande est née d’un incident de production bien réel : sur une flotte de 60 tâches cron, l’une d’elles était morte depuis 5 jours (à cause d’un échec du filtre de contenu) et deux tâches de supervision ne se déclenchaient plus du tout, en silence — et aucune surface existante (list, status, incidents) ne révélait le problème au premier coup d’œil. Les tâches figuraient toujours dans la liste, donc tout « avait l’air normal » ; leur next_run_at avait expiré depuis longtemps, mais personne ne vérifiait.

C’est la maladie classique du cron : le planificateur ne se plaint jamais, sauf si vous allez regarder « quand était-ce censé s’exécuter, et est-ce que ça s’est réellement exécuté ? »

hermes cron doctor : une auscultation, sept contrôles

hermes cron doctor est une nouvelle sous-commande de la famille hermes cron (hermes cron [list|create|edit|pause|resume|run|remove|status|runs|doctor|tick]). Elle est en lecture seule — elle ne modifie jamais la configuration des tâches, elle parcourt simplement chaque tâche active et rapporte ses constatations. D’après le code source (_cron_doctor_issues_for_job dans hermes_cli/cron.py), voici ce qu’elle vérifie :

• Dernière exécution échouée : lorsque le last_status enregistré de la tâche n’est pas ok, elle rapporte le last_error concret ;
• Dernière livraison échouée : elle rapporte last_delivery_error, par exemple un message qui n’est jamais arrivé sur votre plateforme de chat ;
• Tâche active sans next_run_at : une tâche active qui ne peut pas planifier sa prochaine exécution est en soi un symptôme ;
• next_run_at en retard : avec une marge de grâce de 15 minutes correspondant au ticker ; un horodatage dépassé affiche « next_run_at is Xm/h overdue — job is not firing (is the scheduler running?) », le signal d’une tâche qui ne se déclenche plus en silence ;
• Tâche sans agent et sans script : une tâche basée uniquement sur un script (no_agent: true) qui n’a pas de script configuré ;
• Problèmes de santé du script : la vérification de santé du script lui-même (par exemple, le fichier qui n’existe pas) ;
• workdir mort : le workdir de la tâche n’existe plus sur le disque.

Toute tâche qui touche l’un de ces points est listée — et ces traces sont précisément les seuls vestiges que laisse une tâche « présente dans la liste mais en réalité morte ».

À quoi ressemble la sortie

Quand tout va bien, elle est agréablement laconique :

✓ Cron doctor found no issues
  Checked 12 active job(s).

Quand des problèmes existent, elle liste chaque problème par tâche et se termine avec le code 1 :

Cron doctor found 3 issue(s) across 2 job(s):

  cron_daily_report
    - last run failed: content filter rejected output
    - next_run_at is 26.4h overdue — job is not firing (is the scheduler running?)
  nightly_backup
    - workdir not found: /data/backups

Next: fix the listed job config, then run `hermes cron doctor` again.

L’utiliser : le code de sortie est l’essentiel

Une vérification de santé ne vaut son pesant d’or que lorsqu’elle alimente l’automatisation. Le code de sortie est volontairement simple : 0 = tout est sain, 1 = une action est nécessaire. Vous pouvez donc la glisser directement dans un script de supervision :

# Auscultation de la flotte en une ligne chaque matin ; alertez en cas de problème
if ! hermes cron doctor; then
  hermes send -t telegram "cron fleet has a job in trouble — go check!"
fi

Ou lancez simplement hermes cron doctor à la main dès que vous voulez un audit rapide. Comme elle est en lecture seule, il est toujours sûr de l’exécuter.

Quand pouvez-vous l’utiliser

La PR #99479 a été fusionnée le 31 août 2026 et n’est que sur main — la v0.20.6 (sortie le 27 août) ne possède pas encore cette sous-commande. Mettez à jour vers le dernier main pour l’utiliser dès maintenant, ou attendez la prochaine release. La documentation officielle (guide des fonctionnalités cron et référence CLI) la documente déjà.

Les tâches planifiées ne valent leur pesant d’or que lorsqu’elles s’exécutent de manière fiable sans que personne ne les surveille, et la fiabilité commence par savoir qu’elles s’exécutent réellement. hermes cron doctor transforme ce « savoir » en une seule commande. Pour une automatisation plus complète, consultez notre guide complet d’automatisation cron et la supervision cron et les vérifications préalables ; si vos tâches continuent d’échouer en silence à 3h du matin, le guide de réglage du gateway loop-watchdog vaut aussi la peine d’être lu. Référence de commande : hermes cron.