Montagmorgen öffnest du deinen Laptop und stellst fest: Der Job von letzter Nacht ist nie gelaufen — und das schon seit drei Tagen, still und leise. hermes cron list zeigt den Job immer noch an, hermes cron status meldet keinen Fehler, doch es gibt keine Ausgabe, keine Nachricht, kein Log, das dir verrät, was schiefgelaufen ist. Diese Art von stillem Versagen ist schlimmer als ein Fehler: Der Job „sieht gesund aus“, obwohl er längst tot ist. Der neue Befehl hermes cron doctor, am 31. August gemerged, existiert genau für dieses Szenario: ein einziger read-only Befehl, der deine komplette Cron-Flotte von Anfang bis Ende prüft, dir unmissverständlich sagt, was nicht stimmt, und seinen Exit-Code dafür nutzt, direkt in automatisierte Alarme eingebunden zu werden.

Warum „alles in Ordnung“ aussieht, obwohl nichts läuft

Der Befehl ist aus einem echten Produktionsvorfall heraus entstanden: Auf einer Flotte mit 60 Cron-Jobs war ein Job seit 5 Tagen tot (ein Content-Filter-Fehler), und zwei Watchdog-Jobs feuerten stillschweigend nicht — und keine einzige vorhandene Oberfläche (list, status, incidents) zeigte das Problem auf einen Blick. Die Jobs standen immer noch in der Liste, also „sah alles normal aus“; ihre next_run_at war längst abgelaufen, aber niemand schaute nach.

Das ist die klassische Cron-Krankheit: Der Scheduler beschwert sich nicht, solange du nicht selbst nachschaust: „Wann hätte der Job laufen sollen — und ist er wirklich gelaufen?“

hermes cron doctor: ein Check-up, sieben Prüfungen

hermes cron doctor ist ein neuer Unterbefehl der Familie hermes cron (hermes cron [list|create|edit|pause|resume|run|remove|status|runs|doctor|tick]). Er ist read-only — er verändert niemals die Job-Konfiguration, sondern geht einfach jeden aktivierten Job durch und meldet Befunde. Laut Quellcode (_cron_doctor_issues_for_job in hermes_cli/cron.py) prüft er Folgendes:

• Letzter Lauf fehlgeschlagen: Wenn der gespeicherte last_status des Jobs nicht ok ist, meldet er den konkreten last_error;
• Letzte Zustellung fehlgeschlagen: Er meldet last_delivery_error, etwa wenn eine Nachricht deine Chat-Plattform nie erreicht hat;
• Aktivierter Job ohne next_run_at: Ein aktiver Job, der seinen nächsten Lauf nicht planen kann, ist selbst schon ein Symptom;
• next_run_at überfällig: Mit einer Toleranz von 15 Minuten (Ticker-Grace); bei einem überfälligen Zeitstempel erscheint die Meldung „next_run_at is Xm/h overdue — job is not firing (is the scheduler running?)“ — das Signal für einen stillschweigend nicht feuernden Job;
• No-Agent-Job ohne Skript: Ein reiner Skript-Job (no_agent: true), für den kein script konfiguriert ist;
• Skript-Gesundheitsprobleme: Der eigene Health-Check des Skripts (zum Beispiel, dass die Datei nicht existiert);
• Toter workdir: Der workdir des Jobs existiert auf der Platte nicht mehr.

Jeder Job, der gegen eine dieser Prüfungen verstößt, wird aufgelistet — und genau diese Spuren sind das Einzige, was ein „in der Liste stehender, aber eigentlich toter“ Job hinterlässt.

So sieht die Ausgabe aus

Wenn alles gesund ist, ist sie angenehm knapp:

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

Liegen Probleme vor, listet sie jedes Problem pro Job auf und beendet sich mit Exit-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.

Einsatz: Der Exit-Code ist der eigentliche Punkt

Ein Health-Check verdient seinen Namen erst, wenn er Automation speist. Der Exit-Code ist bewusst simpel gehalten: 0 = alles gesund, 1 = irgendetwas braucht Aufmerksamkeit. Du kannst ihn also direkt in ein Monitoring-Skript einbauen:

# Täglicher Flotten-Check in einer Zeile; Alarm, wenn etwas nicht stimmt
if ! hermes cron doctor; then
  hermes send -t telegram "cron fleet has a job in trouble — go check!"
fi

Oder du führst hermes cron doctor einfach manuell aus, wann immer du einen schnellen Audit willst. Da er read-only ist, kann er jederzeit gefahrlos laufen.

Wann du ihn nutzen kannst

PR #99479 wurde am 31. August 2026 gemerged und ist nur auf main — v0.20.6 (veröffentlicht am 27. August) hat diesen Unterbefehl noch nicht. Aktualisiere auf das aktuelle main, um ihn jetzt zu nutzen, oder warte auf das nächste Release. Die offizielle Dokumentation (Cron-Feature-Guide und CLI-Referenz) beschreibt ihn bereits.

Geplante Jobs erfüllen ihren Zweck nur, wenn sie zuverlässig laufen, während niemand zusieht — und Zuverlässigkeit beginnt damit, zu wissen, dass sie wirklich laufen. hermes cron doctor macht aus diesem „Wissen“ einen einzigen Befehl. Für ein vollständigeres Automations-Setup schau in unseren kompletten Cron-Automations-Guide und Cron-Monitoring & Preflight-Checks; falls deine Jobs nachts um 3 immer wieder stillschweigend scheitern, lohnt auch der Gateway-Loop-Watchdog-Tuning-Guide einen Blick. Befehlsreferenz: hermes cron.