Zum Inhalt springen

Cron-Ausdrücke: häufige Fehler und Zeitzonenfallen

Monatstag und Wochentag werden mit ODER verknüpft, Schrittwerte setzen zur vollen Stunde zurück, die Falle des 31. Tags, UTC gegenüber Ortszeit und Jobs, die bei der Zeitumstellung ausfallen oder doppelt laufen.

3 Min. LesezeitCron · Zeitplanung · Zeitzone · Integration

Zeitgesteuerte Jobs (nächtlicher Abgleich, Bericht, Sicherung) sind das stille Rückgrat der meisten Integrationen. Weil ein Cron-Ausdruck kurz ist, übersieht man seine Fehler leicht: Der Ausdruck ist gültig, der Job läuft, aber nicht, wann man es erwartet. Die folgenden Fallen begegnen uns beim üblichen Ausdruck mit fünf Feldern (Minute, Stunde, Monatstag, Monat, Wochentag) am häufigsten.

1. Monatstag und Wochentag werden mit ODER verknüpft

„0 9 1 * 1“ als „09:00 Uhr, wenn der 1. ein Montag ist“ zu lesen, ist ein verbreitetes Missverständnis. Sind beide Felder eingeschränkt, verknüpft klassisches (Vixie-)Cron sie mit ODER: Der Job läuft am 1. und außerdem an jedem Montag. Ist eines davon ein Stern, wird wieder UND angewendet. Für eine Bedingung wie „der erste Montag im Monat“ reicht der Ausdruck allein nicht; der Job muss das heutige Datum selbst prüfen.

2. Ein Schrittwert setzt zur vollen Stunde zurück

„*/7 * * * *“ sieht nach „alle sieben Minuten“ aus; tatsächlich sind die Minuten 0, 7, 14, ... 56, und zur vollen Stunde folgt wieder 0. Der Abstand nach 56 beträgt also 4 Minuten. Schritte, die 60 nicht teilen (7, 8, 25 ...), laufen ungleichmäßig. Braucht man wirklich ein gleichmäßiges Intervall, wählt man einen Schritt, der 60 teilt (5, 10, 15, 20, 30), oder baut den Scheduler auf „seit dem letzten Lauf“ auf.

3. Monate ohne 31. Tag

„0 0 31 * *“ läuft nicht jeden Monat, sondern nur in den sieben Monaten mit 31 Tagen. Für „Monatsende“ wählt man meist einen sicheren Tag wie den 28., oder der Job läuft täglich und prüft, ob morgen der 1. ist. Im Februar gibt es den 30. und 31. nie, den 29. nur in Schaltjahren.

4. Zeitzone: was sagt der Server?

Die Zeitzone eines Cron-Ausdrucks ist die der Umgebung, in der der Job läuft, in den meisten Cloud-Umgebungen UTC. UTC 06:00 ist in der Türkei (UTC+3, keine Sommerzeit) 09:00. Für „jeden Morgen um 09:00“ muss der Ausdruck auf einem UTC-Server „0 6 * * *“ lauten. Wechselt die Umgebung (vom lokalen Rechner in die Cloud), wechselt auch die Zeitzone, und der Job verschiebt sich um drei Stunden. Notieren Sie daher neben dem Ausdruck, in welcher Zeitzone er geschrieben wurde.

5. Zeitumstellung

In einer Zeitzone mit Sommerzeit fehlt bei der Frühjahrsumstellung eine Stunde: In Deutschland springt die Ortszeit am letzten Märzsonntag von 02:00 auf 03:00, und „30 2 * * *“ läuft an diesem Tag womöglich nicht. Im Herbst gibt es eine Stunde doppelt, und derselbe Job kann zweimal laufen. Das Verhalten hängt vom Scheduler ab. Gegenmaßnahme: kritische Jobs in UTC planen oder den Job so schreiben, dass ein erneuter Lauf nicht schadet (idempotent).

6. Syntax anderer Systeme

Quartz und ähnliche Werkzeuge nutzen sechs oder sieben Felder mit Sekundenfeld und Sonderzeichen wie „?“, „L“ und „W“. In Standard-Cron eingefügt, ist ein solcher Ausdruck ungültig oder bedeutet etwas anderes. Beim Wochentag stehen 0 und 7 beide für Sonntag; Namen (MON, JAN) werden nicht überall unterstützt.

Vor dem Lauf ansehen

Geben Sie den Ausdruck in den Cron-Ausdruck-Erklärer ein: Er erklärt ihn in Alltagssprache, zeigt für die gewählte Zeitzone die nächsten 10 Ausführungszeiten und warnt vor Fallen wie der ODER-Regel. Zum Umrechnen von Zeitstempeln gibt es den Zeitstempel-Umrechner, für das Wiederholungsverhalten den API-Retry-Simulator. Für die Durchsicht Ihrer Integrationszeitpläne schreiben Sie uns.

Lassen Sie uns das für Ihr Werk besprechen