Cron-Parser & Crontab-Tester

Cron-Parser & Crontab-Tester

Cron-Ausdrücke in lesbare Zeitpläne übersetzen. Prüfen Sie Ausführungszeitpunkte über Zeitzonen hinweg, validieren Sie Crontab-Syntax und berechnen Sie künftige Termine.

Vorkonfigurierte Vorlagen (Presets)
Token-Anzahl5/5
MIN
*/5
HOUR
*
DOM
*
MON
*
DOW
*
AusführungsrhythmusEvery 5 minutes past every hour.
Übergeordnete ZeitparameterOverrun-sicher
Geschätzte Ausführungsdauer1 Min.
Ausführungspipeline (SVG)In-Memory
LEX5 TokensASTAusführungs-BitmaskePOSIXCleanRUNSafeSLOT10 Ausgaben
Bevorstehende Ausführungstermine(10 occurrences)
#Lokale ZielzeitWochentagCountdown / VerbleibendJitter-ZeitfensterUTC-Zeitstempel (ISO 8601)
1Nov 03, 2026, 03:20Tuein 3m 19sexact2026-11-03T03:20:00.213Z
2Nov 03, 2026, 03:25Tuein 8m 19sexact2026-11-03T03:25:00.213Z
3Nov 03, 2026, 03:30Tuein 13m 19sexact2026-11-03T03:30:00.213Z
4Nov 03, 2026, 03:35Tuein 18m 19sexact2026-11-03T03:35:00.213Z
5Nov 03, 2026, 03:40Tuein 23m 19sexact2026-11-03T03:40:00.213Z
6Nov 03, 2026, 03:45Tuein 28m 19sexact2026-11-03T03:45:00.213Z
7Nov 03, 2026, 03:50Tuein 33m 19sexact2026-11-03T03:50:00.213Z
8Nov 03, 2026, 03:55Tuein 38m 19sexact2026-11-03T03:55:00.213Z
9Nov 03, 2026, 04:00Tuein 43m 19sexact2026-11-03T04:00:00.213Z
10Nov 03, 2026, 04:05Tuein 48m 19sexact2026-11-03T04:05:00.213Z
Nächste AusführungSyntax valide
Ausführungsfrequenz5-Felder (Standard-POSIX)
Läufe pro Jahr10 SLOTS
Feldmodus & Dialektin 3m 19s
Kollisions- & Overrun-Status24 / 24 HRS
AST-Validierungsstatus100 % lokal (Browser)
Technische Referenz & Architektur-Leitfaden

Cron Expression Parser & Crontab Tester — Referenzhandbuch

Cron-Expressions in verständliche Zeitpläne parsen. Nächste Ausführungszeitpunkte über Zeitzonen hinweg berechnen, Crontab-Syntax validieren und anstehende Läufe präzise prognostizieren.

Cron Expression Parser & Crontab Tester — Referenzhandbuch — Client-seitige In-Memory-Architektur und Datenfluss
Cron Expression Parser & Crontab Tester — Referenzhandbuch — Client-seitige In-Memory-Architektur und Datenfluss

Wichtige Parameter & Einstellungen

Minuten-Feld (Feld 1 in POSIX, Feld 2 in Quartz)Integer-Menge [0–59], Asterisk (*), Schritt (/n), Bereich (a-b), Liste (,)

Definiert die exakte Minute der Stunde, in der der Job startet (0–59). Die Auswertung erfolgt über 60-Bit-Integer-Bitmasken mit O(1)-Prüfkomplexität; die Schritt-Syntax */15 löst zu den Minuten 0, 15, 30 und 45 jeder Stunde aus.

Standard: 0 (Volle Stunde)
Stunden-Feld (Feld 2 in POSIX, Feld 3 in Quartz)Integer-Menge [0–23] im 24-Stunden-Format

Bestimmt die Stunde des Tages in 24-Stunden-Notation (0–23), wobei 0 für Mitternacht (00:00 Uhr) und 23 für 23:00 Uhr steht. Der Bereich 9–17 deckt typische ISO-8601-Geschäftszeiten über IANA-Zeitzonen hinweg ab.

Standard: * (Jede Stunde)
Tag-des-Monats-Feld (Feld 3 in POSIX, Feld 4 in Quartz)Integer-Menge [1–31], Fragezeichen (?), Letzter (L), Nächster Werktag (W)

Bestimmt den Kalendertag des Monats von 1 bis 31. Ungültige Datumswerte jenseits der Monatslänge (z. B. der 31. April oder 30. Februar) werden bei der Rollover-Verifikation sicher übersprungen.

Standard: * (Jeder Tag)
Monats-Feld (Feld 4 in POSIX, Feld 5 in Quartz)Integer-Menge [1–12] oder 3-Buchstaben-Aliase [JAN-DEC]

Bestimmt den Kalendermonat von 1 (Januar) bis 12 (Dezember). POSIX-Systeme unterstützen case-insensitive 3-Buchstaben-Kürzel (JAN–DEC), die intern auf eine 12-Bit-Integer-Bitmaske abgebildet werden.

Standard: * (Jeder Monat)
Wochentags-Feld (Feld 5 in POSIX, Feld 6 in Quartz)Integer-Menge [0–7] oder 3-Buchstaben-Aliase [SUN-SAT], N-ter Tag (#), Letzter (L)

Bestimmt den Wochentag. Unter POSIX IEEE 1003.1 und Vixie cron stehen sowohl 0 als auch 7 für Sonntag (1=Montag, ..., 6=Samstag). Case-insensitive Kürzel (SUN–SAT) verhindern Off-by-One-Dialektfehler.

Standard: * (Jeder Wochentag)
Sekunden-Feld (Feld 1 in Quartz / Spring, entfällt in POSIX)Integer-Menge [0–59] hochauflösende Sekunden

Erweitertes erstes Feld für hochauflösende Zeittakte in 6-Feld-Schedulern (Quartz, Spring Framework). Standard-UNIX-Crontabs mit 5 Feldern unterstützen keine Sekunden und stufen führende sechste Tokens als Syntaxfehler ein.

Standard: 0 (Null Sekunden)
Jahres-Feld (Optionales Feld 7 in Quartz, Feld 6 in AWS EventBridge)Integer-Menge [1970–2099], Asterisk (*), entfällt in POSIX

Optionales oder obligatorisches abschließendes Kalenderjahr-Feld in Enterprise-Schedulern, um wiederkehrende Jobs ohne unendliche Ausführungsschleifen auf historische oder künftige Epochen-Jahre zu begrenzen.

Standard: * (Unbegrenzt / Jedes Jahr)

Profi-Tipps & Best Practices

POSIX Tag-des-Monats und Wochentag verhalten sich als logisches ODER, nicht UND

In Standard-Vixie- und POSIX-IEEE-1003.1-Cron-Spezifikationen werden Tag-des-Monats (Feld 3) und Wochentag (Feld 5) mit einer logischen ODER-Bedingung verknüpft, sobald beide Felder keine Wildcards enthalten. Beispiel: 0 0 13 * 5 wird NICHT ausschließlich an einem Freitag, dem 13. ausgeführt, sondern am 13. Tag jedes Monats SOWIE an jedem Freitag jedes Monats. Um die Ausführung strikt auf Freitag, den 13. zu begrenzen, belassen Sie den Wochentag auf * und prüfen den Wochentag direkt im Bash-Befehl: 0 0 13 * * [ $(date +\%u) -eq 5 ] && /opt/backup.sh.

Schrittwerte (*/N) setzen an Feldgrenzen zurück und erzeugen ungleichmäßige Modulo-Lücken

Ein häufiger Entwickler-Irrtum ist die Annahme, dass */25 * * * * kontinuierlich alle 25 Minuten läuft. In der Realität werden Cron-Schrittausdrücke strikt innerhalb der Grenze von 0–59 Minuten ausgewertet: 59 / 25 führt nur zu Ausführungen bei Minute 0, Minute 25 und Minute 50. Wechselt die Uhr zur nächsten Stunde (z. B. von 01:50 auf 02:00), wird das Feld wieder auf Minute 0 zurückgesetzt – es entsteht eine 10-Minuten-Lücke statt eines 25-Minuten-Intervalls. Für echte stundenübergreifende Festintervalle sollten Systemd-Monotonic-Timer (OnUnitActiveSec=25m) oder Token-Bucket-Task-Queues verwendet werden.

Server-Crontabs stets auf UTC standardisieren zur Absicherung gegen Sommerzeit-Kollisionen

Der Betrieb von Crontab-Daemons in lokalen Zeitzonen mit Sommerzeitumstellung (Daylight Saving Time / DST) verursacht schwere Planungsanomalien. Bei der Zeitumstellung im Frühjahr (+1 Stunde) werden Zeitpläne zwischen 02:00 und 02:59 Uhr komplett übersprungen, da diese Uhrzeit nicht existiert. Bei der Herbstumstellung (-1 Stunde) laufen Jobs in diesem Zeitfenster doppelt. Setzen Sie Systemuhren und Crontab-Umgebungen daher immer auf TZ=UTC und berechnen Sie Geschäftszeiten-Offsets statisch, um doppelte oder übersprungene Ausführungen auszuschließen.

Prozentzeichen (%) müssen in Crontab-Befehlsfeldern unter Vixie Cron per Backslash maskiert werden

In Crontab-Dateien besitzt das unmaskierte Prozentzeichen % eine syntaktische Sonderfunktion: Es wird vom Cron-Daemon in ein Zeilenumbruchzeichen (Newline) umgewandelt und alle nachfolgenden Daten werden an die Standardeingabe (stdin) des Befehls weitergeleitet. Inline-Formatierungsbefehle wie date +%Y-%m-%d führen zu stillen Skriptabbrüchen oder kryptischen Syntaxfehlern. Jedes Prozentzeichen muss zwingend als date +\%Y-\%m-\%d maskiert oder der Aufruf in ein separates Shell-Skript ausgelagert werden.

Häufige Fehlerquellen & Fehlerbehebung

⚠️Crontab wirft Syntaxfehler beim Einfügen von 6- oder 7-Feld-Ausdrücken in /etc/crontab unter Linux

Standardmäßige UNIX/Linux-Crontabs erwarten exakt 5 durch Leerzeichen getrennte Felder. Ausdrücke aus Java Quartz, dem Spring Framework oder AWS EventBridge enthalten ein führendes Sekunden-Feld (z. B. 0 0 12 * * ?) oder ein abschließendes Jahres-Feld. Werden diese in Standard-Crontabs eingefügt, interpretiert das System das sechste Token als Benutzernamen oder Befehl, was den Syntaxfehler auslöst. Entfernen Sie das führende Sekunden- und das abschließende Jahres-Token und ersetzen Sie ?-Wildcards durch standardmäßige Asteriske *.

⚠️Cronjob startet zur falschen lokalen Uhrzeit oder zu einer unerwarteten Stunde

Der Crontab-Daemon wertet Zeitpläne anhand der lokalen Hardware- und Kernel-Zeitzone des Systems aus (/etc/timezone oder /etc/localtime). In Cloud-Umgebungen (AWS EC2, Docker-Containern, Kubernetes-Nodes) ist die Standard-Systemzeit meist UTC. Ein Zeitplan wie 0 9 * * 1-5, der für 09:00 Uhr MEZ/MESZ gedacht war, löst um 09:00 Uhr UTC (10:00 bzw. 11:00 Uhr Berliner Zeit) aus. Tragen Sie explizit CRON_TZ=Europe/Berlin am Anfang Ihrer Crontab ein (ab Vixie cron 4.1+) oder rechnen Sie Ihren Zeitplan direkt in UTC um.

⚠️Cronjob wird nicht ausgeführt oder Umgebungsvariablen ($PATH) fehlen

Cron führt Tasks in einer sterilen, nicht-interaktiven Non-Login-Shell mit minimalem Standard-PATH aus (üblicherweise /usr/bin:/bin). Werkzeuge unter /usr/local/bin, ~/.nvm oder /opt/homebrew schlagen mit 'command not found' fehl. Definieren Sie am Anfang Ihrer Crontab explizit PATH=/usr/local/bin:/usr/bin:/bin oder rufen Sie sämtliche Binärdateien mit absoluten Pfaden auf (z. B. /usr/bin/python3 /opt/app/job.py).

⚠️Unerwartet hohe Ausführungshäufigkeit bei Kombination von Tag des Monats und Wochentag

Gemäß POSIX-Standard IEEE 1003.1 wird eine logische ODER-Verknüpfung statt einer UND-Verknüpfung angewandt, wenn sowohl Tag des Monats als auch Wochentag ungleich * definiert sind. Der Job wird ausgeführt, sobald das Datum ODER der Wochentag zutrifft. Um eine gleichzeitige Übereinstimmung zu erzwingen, setzen Sie den Wochentag auf * und integrieren eine POSIX-Datumsprüfung inline in den Befehl: 0 3 1-7 * * [ $(date +\%u) -eq 1 ] && /opt/first-monday.sh.

Häufig gestellte Fragen (FAQ)

Wie wird der exakte nächste Ausführungszeitpunkt eines Cron-Ausdrucks berechnet?▼

Der nächste Ausführungszeitpunkt wird ermittelt, indem ein ISO-8601-Basis-Zeitstempel Minute für Minute (oder Sekunde für Sekunde bei 6-Feld-Engines) weitergestellt und jeder Kandidat gegen vorkompilierte 64-Bit-Bitmasken per bitweisem UND mit O(n)-Schrittkomplexität abgeglichen wird. Sobald alle Felder simultan übereinstimmen – unter Berücksichtigung der POSIX-Vereinigungslogik für Monats- und Wochentag –, wird der Zeitstempel als gültiger Ausführungszeitpunkt erfasst. In Browser-Sandboxes laufen das AST-Parsing und die Projektion vollständig im isolierten JavaScript-Speicher ohne Serverkommunikation ab.

Was ist der Unterschied zwischen Standard-Linux-Cron (5 Felder) und Quartz-Cron (6 Felder)?▼

Standardmäßiges POSIX/Linux-Cron verwendet 5 durch Leerzeichen getrennte Felder (Minute, Stunde, Tag des Monats, Monat, Wochentag) mit einer Auflösung von 1 Minute. Scheduler wie Java Quartz und das Spring Framework nutzen dagegen 6 oder 7 Felder, indem sie ein obligatorisches Sekunden-Feld (0–59) voranstellen und optional ein Jahres-Feld (1970–2099) anfügen. Zudem führt Quartz Sonderzeichen wie ? (nicht festgelegter Wert) und L (letzter Tag des Monats oder der Woche) ein, die in Standard-UNIX-Crontabs Syntaxfehler auslösen.

Was unterscheidet den Asterisk (*) vom Schrägstrich (/Schritt) in der Cron-Syntax?▼

Ein Asterisk (*) fungiert als uneingeschränkte Wildcard und deckt jeden gültigen Integer-Wert im Wertebereich des Feldes ab (z. B. die Minuten 0 bis 59). Ein Schrägstrich (/Schritt) definiert dagegen ein Modulo-Intervall, das nur diskrete Schritte ausgehend von einem Basisindex innerhalb der Feldgrenzen auswertet. Beispielsweise erfasst */15 die Minuten 0, 15, 30 und 45, während 10-30/5 die Schrittfolge strikt auf den Bereich von 10 bis 30 begrenzt (10, 15, 20, 25 und 30).

Warum wird 0 0 13 * 5 an jedem Freitag ausgeführt statt nur an einem Freitag, dem 13.?▼

Nach POSIX-Standard IEEE 1003.1 werten Scheduler die Felder Tag des Monats (Feld 3) und Wochentag (Feld 5) als logische ODER-Disjunktion aus, sobald beide keine Wildcards enthalten. Dadurch feuert der Job sowohl an jedem 13. Tag eines Monats als auch an jedem Freitag – unabhängig vom Datum. Um eine echte UND-Bedingung herzustellen, setzen Sie den Wochentag auf * und prüfen den Wochentag innerhalb des Befehlsskripts per [ $(date +\%u) -eq 5 ].

Welche Bedeutung haben das Fragezeichen (?) und der Buchstabe L in Cron-Ausdrücken?▼

In Cron-Dialekten wie Quartz, Spring und AWS EventBridge kennzeichnet das Fragezeichen (?) einen unbestimmten Wert, um Mehrdeutigkeiten zwischen Tag des Monats und Wochentag aufzulösen. Der Buchstabe L steht für 'Last' (z. B. der letzte Kalendertag des Monats oder mit 5L der letzte Freitag). POSIX-Crontabs nach IEEE 1003.1 kennen weder ? noch L und weisen Ausdrücke mit diesen Zeichen als syntaktisch ungültig zurück.

Wie wirken sich Sommerzeit- und Winterzeitumstellungen (DST) auf geplante Cronjobs aus?▼

Bei der Zeitumstellung im Frühjahr (+1 Stunde) werden Jobs, die im übersprungenen Zeitfenster (typischerweise 02:00:00 bis 02:59:59 Uhr) liegen, komplett ausgelassen, da diese Zeitspanne auf der Systemuhr nicht durchlaufen wird. Bei der Rückstellung im Herbst (-1 Stunde) lösen Jobs in der doppelten Stunde zweimal aus, sofern das System nicht an UTC gebunden ist. Zur Vermeidung von Ausfällen oder Doppelstarts sollten Serveruhren und Crontab-Daemons in Produktionsumgebungen stets auf UTC betrieben werden.

Verwandte Tools & Hilfsprogramme

Alle Tools →