Warum Cronjobs stillschweigend ausfallen — und wie Sie es herausfinden
System-Cron weiß nicht, ob Ihr Job erfolgreich war. Hier erfahren Sie, warum geplante Jobs spurlos ausfallen und welche Muster das beheben.
Es gibt eine besonders unangenehme Art von Ausfall: die stille. Ein geplanter Job hört auf zu funktionieren, nichts alarmiert, und Wochen später entdecken Sie den Schaden — ein leeres Backup, ein Abrechnungslauf, der nie ausgeführt wurde, ein Suchindex, der in der Zeit eingefroren ist. In diesem Beitrag geht es darum, warum das passiert und wie Sie es verhindern.
Cron feuert und vergisst
Das grundlegende Problem ist, dass Unix-cron ein Starter ist, kein
Aufseher. Es führt Ihren Befehl zur festgelegten Minute aus und macht weiter.
Es ist ihm egal, ob der Befehl mit 0 oder 1 beendet wurde, ob er ewig hing oder
einen Stacktrace ausgab. Es gibt kein eingebautes Konzept von Erfolg, Fehler oder
„das hätte vor einer Stunde laufen sollen und tat es nicht“.
So kann ein Job auf alle üblichen Arten scheitern — eine Abhängigkeit ist nicht erreichbar, Zugangsdaten sind abgelaufen, die Platte ist voll, ein Deploy hat einen Pfad geändert — und aus Sicht von Cron ist nichts passiert.
Die drei Fehlerfälle, die niemand bemerkt
- Er lief und scheiterte. Das Skript startete, endete aber mit einem Code ungleich null. Cron bemerkt es nicht; bestenfalls schickt es eine E-Mail an das lokale Postfach von root, das niemand liest.
- Er hing. Der Job startete und endete nie, hielt ein Lock oder leckte Speicher. Der nächste geplante Lauf startet vielleicht gar nicht erst.
- Er lief nie. Der Server wurde neu gestartet, die Crontab falsch bearbeitet, oder die Zeitzone verschob sich durch die Sommerzeit. Der Job feuert einfach nicht — und Abwesenheit ist am schwersten zu bemerken.
Die ersten beiden erfordern, dass der Job sein Ergebnis meldet. Der dritte lässt sich auf der Maschine selbst gar nicht erkennen, denn das, was es Ihnen sagen würde, ist genau das, was kaputt ist.
Die Lösung: Heartbeats und Ausführungsprotokolle
Zwei Muster schließen die Lücke.
Heartbeats verlagern die Frage „Lief er?“ weg von der Maschine, die selbst ausgefallen sein könnte. Ihr Job pingt beim Abschluss einen externen Dienst an; kommt der Ping nicht planmäßig an, alarmiert Sie der Dienst. Entscheidend: Das fängt den Fall „lief nie“ ab — die Stille ist das Signal.
# am Ende Ihres Jobs
curl -fsS https://ping.steadycron.com/<ihr-ping-token>
Ausführungsprotokolle erfassen das Ergebnis jedes Laufs — Status, Dauer, Ausgabe — sodass „Lief der 3-Uhr-Job, und was gab er zurück?“ noch Tage später eine Antwort hat.
Wo SteadyCron passt
SteadyCron macht beides. Es kann Ihre HTTP-Jobs ausführen — mit Wiederholungen und Timeouts, jeden Aufruf protokollierend — und es kann den Cron, den Sie bereits betreiben, per Heartbeat überwachen — und bei verpassten, fehlgeschlagenen und hängenden Läufen über E-Mail, Slack, Discord, Telegram und Webhooks alarmieren.
Wenn Sie je von einem Kunden statt von einem Dashboard von einem kaputten Job erfahren haben, ist genau das das Problem, für das wir es gebaut haben.
Kostenlos starten oder die Anleitung zum Heartbeat-Monitoring lesen.