Cron-Ausdruck: Syntax lesen und nächste Ausführungen berechnen
Lesen Sie einen Cron-Ausdruck Feld für Feld, prüfen Sie die nächsten Ausführungen in UTC oder Ortszeit und meiden Sie Fallen bei Schritten und Zeitzonen.
Ein Cron-Ausdruck wird Feld für Feld gelesen und an Daten geprüft
Eine Zeile wie */15 9-17 * * 1-5 steuert ein Backup, einen CI-Workflow oder einen Kubernetes-CronJob. Sie ist kurz, und kaum jemand liest sie ein zweites Mal. Wer ein Feld falsch liest, bekommt einen Job zur falschen Uhrzeit, doppelt oder gar nicht. Der Cron-Parser nimmt fünf Felder (Minute, Stunde, Tag des Monats, Monat, Wochentag) oder sechs, mit den Sekunden vorn. Er versteht auch Aliasse wie @daily und @hourly. Er zeigt einen Satz, der den Zeitplan zusammenfasst, und den Wert jedes Felds. Dazu nennt er die nächsten 5, 10 oder 25 Ausführungen, in UTC oder in der Zeitzone Ihres Browsers. Die Berechnung läuft in Ihrem Tab, und der Ausdruck wird an niemanden gesendet. Dieser Leitfaden erklärt Syntax und Aliasse und zeigt dann, wie Sie das Ergebnis lesen. Danach folgen die teuren Fallen. Dazu gehören Schritte, die nicht aufgehen, das ODER zwischen Tag des Monats und Wochentag, Daten, die es nicht gibt, die Zeitzone und die Zeitumstellung vom 25. Oktober 2026. Zum Schluss vergleicht er die Dialekte von crontab, Kubernetes, GitHub Actions und AWS EventBridge und rechnet alles noch einmal im Code nach. Verwandte Werkzeuge finden Sie im Hub der Entwickler-Utilities.
Wofür der Parser taugt und wo er endet
Der Parser beantwortet eine einzige Frage: Zu welchen Zeitpunkten löst dieser Ausdruck aus? Damit prüfen Sie ihn, bevor Sie ihn ausrollen.
Der Parser rechnet Daten aus. Den Rest der Kette prüfen Sie anderswo.
Ergebnisse richtig lesen
Geben Sie den Ausdruck in den Cron-Parser ein. Die Daten unten beginnen am Freitag, dem 16. Oktober 2026, um 12:00 UTC. Das Werkzeug rechnet ab dem aktuellen Zeitpunkt, Ihre Daten sehen also anders aus.
Ein Schritt wird innerhalb des Wertebereichs des Felds berechnet. Zu Beginn jedes Bereichs fängt die Zählung bei null an.
Sind beide Felder gesetzt, verknüpft Cron sie nicht mit UND. Der Job läuft, wenn eines von beiden passt, so die Handbuchseite von crontab. Das Werkzeug weist mit einem Hinweis unter dem Zusammenfassungssatz darauf hin.
Ein gültiger Ausdruck kann trotzdem nie auslösen. Das Werkzeug sucht etwa zwei Jahre voraus und sagt es Ihnen.
Vier Fehler, die man erst in Produktion sieht
Der Parser rechnet immer in UTC. Die Option Lokal ändert nur, wie die gefundenen Daten geschrieben werden. 0 9 * * * ergibt 09:00 UTC, was das Werkzeug in einem auf Paris eingestellten Browser am 16. Oktober 2026 als 11:00 schreibt. Ein Cron auf einem Server in der Zeitzone Paris löst um 09:00 Pariser Zeit aus, das sind bis zum 24. Oktober 07:00 UTC und danach 08:00 UTC. Welche Zeitzone gilt, hängt vom System ab, das den Job ausführt. Der Cron-Daemon folgt der Zeitzone des Rechners. Ein Kubernetes-CronJob folgt der des kube-controller-manager, außer .spec.timeZone ist gesetzt. GitHub Actions zählt standardmäßig in UTC.
Europa wechselt am Sonntag, dem 25. Oktober 2026, auf die Winterzeit. Um 03:00 Uhr Sommerzeit ist es wieder 02:00 Uhr. Die USA stellen eine Woche später um, am 1. November. Ein Job mit 30 2 * * * trifft dann auf eine Stunde, die es beim Zurückstellen doppelt gibt und beim Vorstellen gar nicht. Die Implementierungen sind sich nicht einig. Die Debian-Handbuchseite zu cron(8) sagt, Jobs der übersprungenen Stunde liefen kurz nach der Umstellung, und Jobs der wiederholten Stunde würden nicht noch einmal ausgeführt. Die auf man7.org veröffentlichte Seite crontab(5) schreibt das Gegenteil. Eine Uhrzeit, die es nicht gibt, passt nie, und eine wiederholte Uhrzeit löst zweimal aus. GitHub Actions verschiebt mit dem Schlüssel timezone eine Ausführung aus der übersprungenen Stunde auf die nächste gültige Zeit.
Derselbe Zeitplan wird je nach Werkzeug anders geschrieben. AWS EventBridge ergänzt ein Jahresfeld und verlangt ein ? in einem der beiden Tagesfelder. Quartz und Spring stellen die Sekunden an den Anfang. Der Parser lehnt ab, was er nicht kennt, und nennt Feld und Token, zum Beispiel „Ungültiger Wert in Tag des Monats (?)“.
Ein richtiger Ausdruck garantiert weder, dass der Job startet, noch, dass er nur einmal startet. Die Kubernetes-Dokumentation warnt, dass ein Job nur ungefähr zum geplanten Zeitpunkt angelegt wird. Es können zwei Jobs entstehen oder keiner, deshalb müssen Jobs idempotent sein. Die Standardrichtlinie für Parallelität heißt Allow und lässt einen Lauf starten, während der vorige noch arbeitet. Zählt der Controller mehr als 100 verpasste Starts, startet er den Job nicht mehr und protokolliert einen Fehler. GitHub Actions verzögert geplante Läufe bei hoher Last, vor allem zu Beginn jeder Stunde, und kann einzelne verwerfen. In einem öffentlichen Repository werden geplante Workflows nach 60 Tagen ohne Aktivität deaktiviert.
Felder, Aliasse und Dialekte auf einen Blick
Jedes Feld nimmt dieselben Operatoren. Nur die Grenzen unterscheiden sich.
Ein Alias ersetzt den ganzen Ausdruck. Der Parser löst sie im Eingabefeld auf.
Prüfen Sie vor dem Kopieren eines Ausdrucks, was das Ziel versteht.
Der Cron-Parser Schritt für Schritt
Der Cron-Parser analysiert beim Tippen, nach einer kurzen Pause. Die Schaltfläche Parsen oder die Eingabetaste im Feld startet die Berechnung ohne Wartezeit.
Tippen oder eine Voreinstellung wählen
Sechs Voreinstellungen füllen das Feld: alle 5 Minuten, alle 15 Minuten, stündlich, täglich um Mitternacht, werktags um 09:00 und monatlich am 1. Ein Alias wie @daily wird durch seine Form mit fünf Feldern ersetzt.
Den Satz lesen
Bei einfachen Zeitplänen fasst ein Satz den Ausdruck zusammen, zum Beispiel „Alle 15 Minuten“ oder „Um 09:00 an Werktagen (Mo–Fr)“. Sonst zeigt das Werkzeug „Zeitplan-Aufschlüsselung“ und überlässt Ihnen die Felder.
Die Kästchen prüfen
Jedes Kästchen trägt den Namen eines Felds und seinen Wert. Ein Hinweis erscheint, wenn Tag des Monats und Wochentag beide gesetzt sind, als Erinnerung, dass eines von beiden genügt.
Die nächsten Ausführungen lesen
Die Liste nennt die vollständigen Daten, dazu eine Zeile „Nächster“ mit der Zeit bis zur ersten Ausführung. Eine Warnung erscheint, wenn es kein Datum gibt oder die Suche endet, bevor sie genug gefunden hat.
Drei Einstellungen unter dem Eingabefeld ändern, was das Werkzeug berechnet oder zeigt.
Fünf oder sechs Felder
Voreinstellung sind fünf Felder. Beim Wechsel auf sechs steht 0 vorn im Ausdruck, also Sekunden auf null. Beim Zurückgehen auf fünf entfällt diese Null, und das Werkzeug lehnt ab, solange die Sekunden etwas anderes als 0 sind.
Anzuzeigende Läufe
Wählen Sie 5, 10 oder 25. Nehmen Sie 25, um das Muster eines Schritts, eines Monatsendes oder zweier kombinierter Tagesfelder zu sehen.
Zeitzone
UTC ist die Voreinstellung. Lokal nutzt die Zeitzone Ihres Browsers. Ein Etikett über dem Satz erinnert an die Wahl. Die Berechnung bleibt in beiden Fällen in UTC, nur die Schreibweise der Daten ändert sich.
Kopieren
Beschreibung kopieren übernimmt den Satz, Alle kopieren die Liste, und jede Zeile hat eine eigene Schaltfläche Kopieren.
Lehnt das Werkzeug den Ausdruck ab, nennt es den Grund und berechnet nichts.
Leerer Ausdruck
Ein nach der Eingabe geleertes Feld zeigt „Geben Sie einen Cron-Ausdruck ein“.
Falsche Feldanzahl
„Ungültiger Cron-Ausdruck für die gewählte Feldanzahl“ weist auf vier Felder hin, oder auf sechs bei der Einstellung auf fünf. Ändern Sie die Einstellung oder korrigieren Sie die Token.
Ungültiger Wert
Eine Meldung wie „Ungültiger Wert in Stunde (22-2)“ nennt Feld und fehlerhaftes Token, und das Kästchen dieses Felds wird hervorgehoben.
Nicht unterstützter Alias
@reboot und jeder Alias außerhalb der Liste lösen eine Meldung aus, die die akzeptierten Aliasse nennt.
Dieselben Zeitpläne in crontab, Kubernetes, GitHub Actions und Node
Die Zeile gehört in crontab -e. Der Befehl nimmt den Rest der Zeile ein: Ein ungeschütztes % wird dort zum Zeilenumbruch, daher das \% im Beispiel (siehe die Handbuchseite von crontab). Cron führt Ihr Login-Profil nicht aus, geben Sie deshalb den vollen Pfad der Programme an.
Einfaches Beispiel
Die Zeitzone steht in .spec.timeZone, nie in schedule. Prüfen Sie das Manifest mit dem Kubernetes-Validator, bevor Sie es anwenden.
Einfaches Beispiel
Der Workflow löst nur aus, wenn er im Standard-Branch liegt. Der GitHub-Actions-Validator prüft die Datei und der Cron-Parser die Daten.
Einfaches Beispiel
Um die nächsten Ausführungen in einer Zeitzone zu berechnen, wie es ein echtes Cron tut, übergeben Sie die Option tz. Das Beispiel nutzt Version 5 der Bibliothek. Es zeigt den Unterschied zum FastMinify-Parser, der in UTC rechnet: Dieselbe Zeile ergibt für eine Pariser Uhrzeit 07:00 UTC vor dem 25. Oktober 2026 und 08:00 UTC danach.
Einfaches Beispiel
Zusammenfassung
Ein Cron-Ausdruck passt in fünf Felder, und fast jeder Fehler entsteht durch das, was man ihm nicht ansieht. Ein Schritt fängt bei null neu an, zwei Tagesfelder verbinden sich zum ODER, ein Datum existiert nicht, und eine Zeitzone oder Zeitumstellung verschiebt alles. Der Cron-Parser stellt Daten neben die Zeile, sodass Sie diese Fälle vor dem Ausrollen erkennen. Er rechnet in UTC, startet keinen Job und kennt nur die fünf oder sechs Felder und die gängigen Aliasse. Das Ziel zählt so viel wie der Ausdruck, denn crontab, Kubernetes, GitHub Actions, EventBridge und Quartz lesen nicht dieselbe Syntax. Schreiben Sie Jobs, die man gefahrlos wiederholen kann, und beobachten Sie ihren letzten Erfolg. Der Hub der Entwickler-Utilities versammelt die verwandten Werkzeuge.
Einen Cron-Ausdruck im Browser analysieren
Verwandte Artikel
Netzwerk, Maske, Hostbereich und Broadcast eines CIDR berechnen, Bereiche zu minimalen Blöcken zusammenfassen und IPs prüfen, direkt im Browser.
cURL-Kopien formatieren, rohe HTTP-Anfragen und -Antworten parsen und HAR-Exporte lesen, direkt im Browser: nichts wird gesendet oder wiederholt.
Header und Payload eines JWT dekodieren oder ein Test-Token signieren, direkt im Browser: HS256, RS256, ES256, ohne Secret an einen Drittserver zu senden.