Cron ist der älteste und am weitesten verbreitete Job-Scheduler in der Datenverarbeitung – der ursprüngliche Unix-Cron, der 1975 ausgeliefert wurde, und seine Ausdruckssyntax wurde im Wesentlichen unverändert von jedem modernen Planungssystem übernommen, von Unix-Crontabs über Kubernetes-CronJobs bis hin zu Cloud-Schedulern auf AWS, GCP und Azure. Trotz dieser Allgegenwart sind Cron-Ausdrücke bekanntermaßen fehleranfällig, wenn sie von Hand geschrieben werden, und ein einziges falsches Zeichen kann einen täglichen Job in einen stündlichen Job verwandeln, der ein Produktionssystem lahmlegt. In den folgenden Abschnitten werden die 5-Felder-Struktur, die Sonderzeichen, die sie erweitern, und die praktischen Fallstricke erläutert, die selbst erfahrene Ingenieure ins Auge fassen.

Die 5-Felder-Struktur und ihre Bedeutung

Ein Standard-Cron-Ausdruck hat genau 5 durch Leerzeichen getrennte Felder in einer festen Reihenfolge: Minute, Stunde, Tag des Monats, Monat, Wochentag. Jedes Feld akzeptiert eine Zahl innerhalb seines gültigen Bereichs (Minute 0–59, Stunde 0–23, Tag des Monats 1–31, Monat 1–12, Tag der Woche 0–6 mit 0 = Sonntag), einen Platzhalter „*“, der einen beliebigen Wert bedeutet, oder eine der im nächsten Abschnitt beschriebenen speziellen Syntaxen. Die Felder folgen einem chronologischen Vergrößerungsmuster: Die Minute ist am genauesten, der Wochentag ist das allgemeinste für wöchentliche Muster. Ein kniffliges Detail ist das Feld „Wochentag“: In der Vergangenheit waren sich verschiedene Unix-Varianten nicht einig darüber, ob der Sonntag 0 oder 7 war, und der moderne Standard akzeptiert aus Kompatibilitätsgründen beide. Die Felder „Monat“ und „Wochentag“ akzeptieren auch dreibuchstabige Abkürzungen („JAN“-„DEC“, „SUN“-„SAT“), bei denen die Groß-/Kleinschreibung nicht beachtet wird und die häufig besser lesbar sind als numerische Werte. Wenn sowohl der Tag des Monats als auch der Wochentag angegeben sind, verwenden die meisten Cron-Implementierungen die ODER-Logik (der Job wird ausgeführt, wenn einer von beiden übereinstimmt) und nicht die UND-Logik (beide Übereinstimmungen erforderlich). Dies ist eine der häufigsten Ursachen für Verwirrung – „0 0 15 * FRI“ läuft am 15. eines jeden Monats um Mitternacht UND jeden Freitag, nicht nur an Freitagen, die auf den 15. fallen.

Sonderzeichen: Schritt, Bereich, Liste und Platzhalter

Vier Sonderzeichen erweitern die grundlegende Cron-Syntax und erfüllen die meisten realen Planungsanforderungen. Das Sternchen „*“ ist der Platzhalter für jeden Wert: „* * * * *“ löst jede Minute, jede Stunde und jeden Tag aus. Der Schrägstrich „/“ führt Schrittwerte ein: „*/15“ im Minutenfeld wird bei Minute 0, 15, 30, 45 ausgelöst – alle 15 Minuten. Schritte können mit Bereichen kombiniert werden: „9-17/2“ wird zu den Stunden 9, 11, 13, 15, 17 ausgelöst. Der Bindestrich „-“ leitet Bereiche ein: „9-17“ deckt im Stundenfeld die Zeit von 9:00 bis einschließlich 17:00 Uhr ab. Das Komma „,“ leitet Listen ein: „1,3,5“ im Feld „Wochentag“ bedeutet Montag, Mittwoch, Freitag. Diese können frei kombiniert werden – „0 9,12,17 * * 1-5“ feuert wochentags um 9.00 Uhr, 12.00 Uhr und 17.00 Uhr. Einige Cron-Implementierungen fügen über diese Grundlagen hinaus zusätzliche Besonderheiten hinzu. Quartz (wird von vielen Java-Planungsbibliotheken verwendet) fügt „L“ (letzter Tag des Monats/der letzten Woche), „W“ (nächster Wochentag) und „#“ (n-tes Vorkommen eines Tages in einem Monat) hinzu. Jenkins fügt „H“ für Hash-Werte hinzu, die identische Zeitpläne über die Zeit verteilen, um Thundering-Herd-Effekte zu vermeiden. Dieses Tool zielt auf das standardmäßige 5-Felder-Format ab, das von Unix crontab, AWS EventBridge, GCP Cloud Scheduler, Azure Logic Apps und den beliebtesten Planungsbibliotheken wie Node-Cron und Python-Crontab verwendet wird.

Praktische Fallstricke, die selbst erfahrene Ingenieure in den Bann ziehen

Mehrere Cron-Probleme verursachen immer wieder Produktionsstörungen, selbst bei Teams, die Cron täglich verwenden. Erstens die Zeitzonenbehandlung: Cron-Ausdrücke werden standardmäßig in der lokalen Zeitzone des Systems ausgeführt, was bedeutet, dass Sommerzeitübergänge im März und November dazu führen können, dass Jobs einen Tag überspringen oder je nach Übergangsrichtung doppelt ausgeführt werden. Konfigurieren Sie Cron-Jobs nach Möglichkeit immer so, dass sie in UTC ausgeführt werden, oder testen Sie die Sommerzeit-Übergangswochenenden explizit, bevor Sie zeitkritische Zeitpläne bereitstellen. Zweitens fängt die oben besprochene ODER-Logik zwischen Tag des Monats und Wochentag Ingenieure ein, die UND-Logik erwarten. Wenn Sie möchten, dass ein Job nur an Freitagen ausgeführt wird, die auf den 15. fallen, können Sie dies nicht in Standard-Crons ausdrücken – Sie müssen die AND-Logik im Anwendungscode verwenden, nachdem der Job ausgelöst wurde. Drittens, Schaltjahr-Randfälle: „0 0 29 2 *“ läuft nur am 29. Februar, was alle 4 Jahre einmal vorkommt. Es ist einfach, dies einmal zu testen und festzustellen, dass es scheinbar nicht funktioniert. Viertens werden „@reboot“ und andere Sonderfunktionen wie „@daily“ oder „@hourly“ von vielen Implementierungen unterstützt, sind aber nicht portierbar – Cloud-Scheduler akzeptieren sie im Allgemeinen nicht. Verwenden Sie aus Gründen der Portabilität immer das explizite 5-Felder-Formular. Fünftens können sich lang laufende Jobs überschneiden: Wenn ein Job alle 5 Minuten ausgeführt wird, die Ausführung jedoch 7 Minuten dauert, werden zwei Instanzen gleichzeitig ausgeführt. Umschließen Sie dies mit einer Sperrdatei („flock“ unter Linux) oder nutzen Sie die Koordination auf Anwendungsebene, um dies zu verhindern.