Cron-Ausdrucks-Erklärer

Funktionsweise

1. Cron-Ausdruck eingeben: Fügen Sie einen beliebigen 5-Feld- oder 6-Feld-Cron-String wie 0 9 * * 1-5 ein.
2. Klartext-Erklärung lesen: Das Tool zeigt sofort eine menschenlesbare Beschreibung, wann der Job läuft.
3. Nächste Ausführungszeiten sehen: Eine Liste der nächsten 5–10 geplanten Ausführungszeiten wird basierend auf dem aktuellen Datum und der aktuellen Uhrzeit angezeigt.
4. Validieren: Ungültige Ausdrücke werden mit spezifischen Fehlermeldungen hervorgehoben, die erklären, was schief lief.

Ein halbes Jahrhundert Minuten-Ticks

cron ist der älteste Scheduler, der auf den meisten Servern der Welt noch ununterbrochen täglich im Einsatz ist. Sein erster Auftritt im historischen Protokoll ist Mai 1975, als eine frühe Version von AT&T Bell Laboratories als Teil des Research-Unix-Zweigs ausgeliefert wurde. Der Name ist eine Anspielung auf Chronos, die griechische Personifikation der Zeit, und das Design ist mit seltsamer Anmut gealtert: dieselben fünf durch Whitespace getrennten Felder, die Bell-Labs-Ingenieure Mitte der 1970er in /usr/lib/crontab tippten, treiben heute noch Kubernetes CronJobs, GitHub-Actions-Schedules und das nächtliche Datenbank-Backup auf einem virtuellen privaten Server irgendwo in Frankfurt genau jetzt an. Die Implementierung von 1975 war minimal, es gab eine einzige crontab, im Besitz von root, die die ganze Maschine bediente. Wenn ein Nutzer einen wiederkehrenden Job wollte, bat er den Administrator, eine Zeile von Hand hinzuzufügen. cron wanderte mit Version 7 Unix, veröffentlicht 1979, in die weitere Welt. Robert Brown und Keith Williamson an der Purdue University erweiterten cron Ende 1979, um mehrere Nutzer zu handhaben, und führten den crontab -e-Workflow pro Nutzer ein. Die entscheidende Neuschreibung kam, als Paul Vixie vixie-cron 1.0 am 6. Mai 1987 veröffentlichte; vixie-cron formalisierte die Sonderzeichen und führte die Abkürzungen @reboot, @hourly, @daily, @weekly, @monthly, @yearly ein. Vixie 3.0 (27. Dezember 1993) fügte Schrittwerte (/) hinzu und wurde mit kleineren Patches in nahezu jede Linux-Distribution und jedes BSD jener Ära aufgenommen. POSIX zog 1992 nach (IEEE Std 1003.2-1992). Jede Marotte des modernen cron (die um eins versetzte Sonntagsnummerierung, der Union-vs.-Schnittmenge-Bug der Tagesfelder) ist eine Narbe dieser Evolution; nichts davon wurde in einem Wurf entworfen.

Anatomie eines fünf-feldigen Ausdrucks

Ein Standard-cron-Ausdruck besteht aus fünf leerzeichengetrennten Feldern. Von links nach rechts gelesen fragen sie: welche Minute, welcher Stunde, welches Tages-im-Monat, welches Monats, welches Wochentags? Die genauen Wertebereiche sind in POSIX-cron nicht verhandelbar: Minute 0-59, Stunde 0-23, Tag-im-Monat 1-31, Monat 1-12, Wochentag 0-7, wobei sowohl 0 als auch 7 für Sonntag stehen. Jedes Feld akzeptiert fünf Operatoren, die sich frei kombinieren lassen: * bedeutet jeden gültigen Wert; , trennt eine Liste diskreter Werte (0,15,30,45 * * * * läuft zur vollen Stunde, viertel nach, halb und drei viertel jede Stunde); - ist ein inklusiver Bereich (9-17 im Stundenfeld bedeutet 9, 10, 11, 12, 13, 14, 15, 16, 17); / ist ein Schrittwert (*/15 im Minutenfeld bedeutet jede fünfzehnte Minute beginnend bei null, also 0, 15, 30, 45). Monate und Wochentage können auch als Drei-Buchstaben-Abkürzungen geschrieben werden: JAN-DEC und SUN-SAT. Ein ausgeführtes Beispiel: */15 9-17 * * 1-5 dekodiert zu alle fünfzehn Minuten während der Stunden 9 bis 17 inklusive, an jedem Tag des Monats, in jedem Monat des Jahres, von Montag bis Freitag: „jede Viertelstunde während der Geschäftszeiten an Werktagen“.

Die Falle Tag-im-Monat / Wochentag

Die folgenreichste Marotte von cron (diejenige, die seit fünfunddreißig Jahren Ausfälle, verpasste Backups und stillschweigend falsche Abrechnungsläufe in der Produktion verursacht hat) ist die Art, wie cron die Felder Tag-im-Monat und Wochentag kombiniert, wenn beide eingeschränkt sind. Die POSIX-Formulierung ist hier ungewöhnlich präzise: „wenn sowohl ‚Tag des Monats‘ (Feld 3) als auch ‚Tag der Woche‘ (Feld 5) eingeschränkt sind (kein ‚*‘ enthalten), dann muss eines oder beide auf den aktuellen Tag passen“. Mit anderen Worten: wenn keines der beiden Felder ein Wildcard ist, nimmt cron die Vereinigung der beiden, der Job läuft an jedem Tag, der einer der Beschränkungen entspricht. Das ist das Gegenteil dessen, was die meisten Nutzer annehmen. 0 0 13 * 5 laut zu lesen („Mitternacht am 13., am Freitag“) klingt natürlich nach einer Schnittmenge: nur Freitag der 13. In vixie-cron und seinen Nachfahren bedeutet es tatsächlich „jeden 13. des Monats und jeden Freitag“ und feuert etwa neunmal im Monat. Schlimmer noch, vixie-cron entscheidet anhand des nur ersten Zeichens jedes Tagesfelds, ob Vereinigung oder Schnittmenge verwendet wird. Paul Vixie selbst erkannte das Verhalten als Bug an, weigerte sich aber, es zu ändern, mit dem Hinweis, eine Korrektur würde gegen das Prinzip des geringsten Erstaunens verstoßen, Millionen von crontabs waren bereits in der Annahme geschrieben, das bestehende Verhalten sei beabsichtigt. Der Bug ist daher heute ein Feature, unsterblich und sich selbst verbreitend. Das pragmatische Mentalmodell: Wenn Sie sich dabei ertappen, sowohl Tag-im-Monat als auch Wochentag zu beschränken und Sie tatsächlich die Schnittmenge wollen (z. B. „der zweite Dienstag jedes Monats“), verwenden Sie den #-Operator in Implementierungen, die ihn unterstützen (Quartz, cronie mit Erweiterungen): 0 12 ? * 2#2. In reinem POSIX-cron ist die Schnittmenge in einem einzelnen Ausdruck wirklich nicht ausdrückbar, und Sie müssen innerhalb des Skripts filtern, das der cron-Job aufruft.

Die Abkürzungs-Makros

• @yearly / @annually = 0 0 1 1 *: Mitternacht, 1. Januar
• @monthly = 0 0 1 * *: Mitternacht, am Ersten jedes Monats
• @weekly = 0 0 * * 0: Mitternacht, Sonntag
• @daily / @midnight = 0 0 * * *: Mitternacht jeden Tag
• @hourly = 0 * * * *: zur vollen Stunde
• @reboot: speziell: feuert einmal, wenn der cron-Daemon startet (nicht einmal pro System-Reboot, auf Systemen, auf denen cron gestoppt und neu gestartet werden kann, wird @reboot erneut feuern)

Diese Abkürzungen sind nicht POSIX. Strikt POSIX-konforme Umgebungen lehnen @daily ab; in der Praxis unterstützt jede cron-Implementierung, der ein Leser wahrscheinlich begegnet (vixie-cron, cronie, fcron, ISC cron, Container-Images), sie.

Die Dialekte, Standard vs. Quartz vs. AWS vs. K8s vs. systemd

Der „cron-Ausdruck“ ist heute eine kleine Familie gegenseitig inkompatibler Dialekte. Standard-cron mit 5 Feldern (POSIX, vixie-cron, cronie): Minute Stunde Tag-im-Monat Monat Wochentag, der universelle kleinste gemeinsame Nenner. Quartz Scheduler (6 oder 7 Felder, Java-Ökosystem): Sekunden Minuten Stunden Tag-im-Monat Monat Wochentag [Jahr]; führt ?, L (last), W (weekday), # (n-ter Wochentag des Monats) ein. Springs @Scheduled und Spring Boot verwenden Quartz. Kubernetes CronJob verwendet Standard-cron mit 5 Feldern, mit einem separaten spec.timeZone-Feld, das in K8s 1.27 GA wurde (die CronJob-Ressource selbst wurde in 1.21 im April 2021 GA); das Zeitzonenformat ist die IANA-tz-Datenbank (Europe/Berlin, America/New_York). GitHub-Actions-cron-Schedules verwenden POSIX-cron mit 5 Feldern und laufen in UTC. cron in AWS EventBridge verwendet 6 Felder (Minuten Stunden Tag-im-Monat Monat Wochentag Jahr), verlangt den ?-Operator entweder bei Tag-im-Monat oder Wochentag (man darf nicht beide einschränken) und verwendet 1-7 mit SUN=1, was bedeutet, dass ein EventBridge-Ausdruck 0 12 ? * 2 * mittags am Montag läuft, nicht am Dienstag. systemd-Timer verwenden eine völlig andere Syntax (OnCalendar=*-*-* 02:00:00) und ersetzen cron auf modernem Linux für Scheduling auf Systemebene allmählich, obwohl beide auf jeder großen Distro nebeneinander ausgeliefert werden. Cloud Scheduler (Google Cloud) verwendet Standard-cron mit 5 Feldern und expliziter Zeitzonenkonfiguration. Ausdrücke zwischen Plattformen zu übersetzen, erfordert sorgfältige Aufmerksamkeit: ein kopierter EventBridge-Schedule läuft in vixie-cron am falschen Wochentag, wegen der Verschiebung der Wochentag-Nummerierung.

Häufige Muster, die man sich merken sollte

• */15 * * * *: alle 15 Minuten (00:00, 00:15, 00:30, 00:45 jeder Stunde)
• */15 9-17 * * 1-5: alle 15 Minuten während Geschäftszeiten, nur an Werktagen
• 0 9 * * 1-5: jeden Werktag um 9 Uhr
• 0 6,18 * * *: zweimal täglich, um 6 und um 18 Uhr (über eine Liste, keinen Bereich)
• 0 0 1 * *: Mitternacht am 1. jedes Monats
• 0 0 L * *: Mitternacht am letzten Tag jedes Monats (L ist eine Quartz/cronie-Erweiterung)
• 0 3 1-7 * 1: erster Montag jedes Monats um 3 Uhr (nutzt den Union-Bug absichtlich: trifft auf Tage 1-7 UND auf Montage, aber die einzigen Tage, die in jedem gegebenen Monat beide Beschränkungen erfüllen, sind der erste Montag)
• 0 0 1 1,4,7,10 *: Mitternacht am ersten Tag jedes Kalenderquartals
• 0 0 * * 0,6: Mitternacht am Wochenende

Häufige Stolperfallen

Zeitzone. cron verwendet standardmäßig die lokale Zeit des Systems, überraschend auf Cloud-Maschinen, die standardmäßig auf UTC stehen. Ein 9-Uhr-cron-Job auf einem UTC-Server feuert um 4 Uhr Eastern. Moderne Scheduler (Kubernetes 1.27+, AWS EventBridge, Cloud Scheduler) haben explizite Zeitzonenfelder hinzugefügt; klassischer cron nicht. Die Regel „*/N beginnt bei 0“. */15 ist 0, 15, 30, 45, nicht 5, 20, 35, 50. Um bei einem Offset ungleich null zu beginnen, müssen Sie aufzählen (5,20,35,50) oder die Quartz-eigene Syntax 5/15 verwenden. Die 60-Minuten-Stau-Falle. Ein Job, der länger als sein Schedule-Intervall dauert, kann sich stauen, drei 30-minütige Backups, die alle 15 Minuten feuern, werden sich überlappen. Die Standardabhilfe ist flock(1): * * * * * /usr/bin/flock -n /tmp/myjob.lock /path/to/myjob stellt sicher, dass nur eine Instanz gleichzeitig läuft; das -n-Flag macht das Lock-Akquirieren nicht-blockierend, sodass nachfolgende Aufrufe still beenden statt sich anzustellen. DST-Anomalien. Ein cron-Job, der für 02:30 geplant ist, feuert am Tag der Zeitumstellung zurück zweimal und am Tag der Zeitumstellung vor gar nicht. cron hat kein Konzept von „Wanduhr-Zeit unter Berücksichtigung der Sommerzeit“; wenn Ihr Zeitplan DST-Übergänge vermeiden muss, verankern Sie ihn in einer nicht betroffenen Stunde (3 Uhr oder später in den meisten Zeitzonen) oder verwenden Sie einen Scheduler, der Zeitzonen-Semantik versteht. PATH-Stripping. cron-Jobs laufen mit einem minimalen PATH (/usr/bin:/bin) und einer nahezu leeren Umgebung; Skripte, die in Ihrer interaktiven Shell funktionieren, können in cron fehlschlagen, weil node, python3 oder aws nicht im geerbten PATH sind. Setzen Sie entweder PATH= oben in der crontab oder verwenden Sie absolute Pfade im cron-Befehl. E-Mail-Überlauf. Standardmäßig schickt cron die Ausgabe jedes Jobs an das lokale Postfach des Nutzers; auf einem Server ohne konfigurierten Mail-Service füllt das stillschweigend /var/spool/mail, bis die Festplatte voll ist. Entweder leiten Sie die Ausgabe um (>/dev/null 2>&1), setzen MAILTO="" oben in der crontab oder konfigurieren tatsächlich einen Mail-Forwarder.

Moderne Alternativen, wann man zu etwas anderem greift

cron ist hervorragend für einfache wiederkehrende Aufgaben auf einer einzelnen Maschine. Schlecht ist es bei: verteiltem Scheduling (derselbe Job einmal über eine Flotte ausgelöst statt einmal pro Maschine), ereignisgesteuerten Triggern (Ausführung, wenn eine Queue eine Nachricht empfängt, nicht nach Uhr), Monitoring (cron schlägt still fehl, wenn der Job mit Code ungleich null beendet, sofern Sie kein E-Mail-Forwarding eingerichtet haben), Wiederholungen (kein eingebauter Mechanismus, fehlgeschlagene Jobs laufen im nächsten Zyklus erneut und akkumulieren Zustand) und Abhängigkeiten (Job B nur ausführen, nachdem Job A erfolgreich abgeschlossen ist). Für diese Fälle lautet die moderne Antwort eines von: Kubernetes CronJob (cluster-bewusstes Scheduling mit Retry- und Parallelism-Policies), AWS EventBridge + Lambda oder Step Functions (ereignisgesteuert mit eingebauter Beobachtbarkeit), Apache Airflow oder Prefect (DAG-basierte Workflow-Orchestrierung mit expliziten Abhängigkeiten), Temporal (langlebige Workflow-Ausführung), healthchecks.io (ein „Totmannschalter“, der Sie informiert, wenn ein cron-Job nicht planmäßig läuft). Für wiederkehrende Aufgaben auf einer einzelnen Maschine im Jahr 2026 ist schlichtes cron immer noch die richtige Antwort; für alles andere ist eine der Alternativen die zusätzliche Einrichtung wert.

Häufig gestellte Fragen

Was bedeutet * in einem cron-Ausdruck?

Ein Sternchen (*) in einem cron-Feld bedeutet „jeden gültigen Wert“, jede Minute, jede Stunde, jeden Tag, jeden Monat, jeden Wochentag. * * * * * läuft jede Minute jedes Tages. Das Sternchen ist auch in den Feldern Tag-im-Monat und Wochentag wegen der Union-vs.-Schnittmenge-Falle besonders: wenn eines der Tagesfelder ein führendes * hat, verwendet vixie-cron den Schnittmengen-Modus; wenn keines ein * hat, verwendet es den Union-Modus und läuft auf der Vereinigung beider Beschränkungen.

Wie lasse ich einen cron-Job alle 15 Minuten laufen?

Verwenden Sie die Schritt-Notation: */15 * * * * läuft alle 15 Minuten, um xx:00, xx:15, xx:30 und xx:45. Beachten Sie, dass */N immer bei 0 beginnt; Sie können */15 nicht verwenden, um „alle 15 Minuten beginnend bei Minute 5“ zu meinen, dafür schreiben Sie 5,20,35,50 * * * *. cron im Quartz-Dialekt unterstützt 5/15 als nicht-Standard-Alternative.

Was ist der Unterschied zwischen cron und at?

cron führt Jobs nach einem wiederholenden Zeitplan aus (jede Minute, täglich, wöchentlich). Der Befehl at plant einen einmaligen Job, der zu einem bestimmten zukünftigen Zeitpunkt ausgeführt wird, at 14:30 tomorrow stellt einen Job für genau diesen Moment in die Warteschlange. Verwenden Sie cron für wiederkehrende Aufgaben und at für einmalige zukünftige Ausführungen. Beide stammen von derselben Bell-Labs- / vixie-cron-Linie ab und wurden auf den meisten Systemen schließlich im selben Daemon zusammengeführt.

Warum trifft mein cron-Job nicht das, was ich erwartet hatte?

Die fünf häufigsten Ursachen, in grober Reihenfolge der Häufigkeit: (1) Verwirrung Tag-im-Monat vs. Wochentag (cron verwendet die Vereinigung beider, wenn beide eingeschränkt sind, nicht die Schnittmenge. (2) Zeitzone) cron verwendet standardmäßig die lokale Zeit des Servers, auf Cloud-Maschinen oft UTC. (3) PATH-Probleme, der PATH Ihrer interaktiven Shell wird nicht vererbt, sodass Befehle, die im Prompt funktionieren, in cron fehlschlagen können. (4) Die */N-immer-bei-0-Falle. (5) Ausgabe wird nirgendwo erfasst, fehlgeschlagene Jobs verschwinden still, wenn Sie keine E-Mail eingerichtet oder die Ausgabe in eine Logdatei umgeleitet haben. Das „nächsten 10 geplanten Läufe“-Panel dieses Erklärers ist die billigste Möglichkeit, vor dem Deployment zu überprüfen, was Ihr Ausdruck tatsächlich bedeutet.

Unterstützt das auch nicht-standard-cron-Formate?

Es behandelt das Standard-POSIX/vixie-cron mit 5 Feldern, die Quartz/Spring-Variante mit 6 Feldern und Sekunden sowie die Sonderzeichen @hourly, @daily, @weekly, @monthly, @yearly und @reboot. Es behandelt nicht die vollen Quartz-Erweiterungen (L, W, #) oder die 1-basierte Wochentagsnummerierung von AWS EventBridge, dafür verwenden Sie den plattformeigenen Validator vor dem Deployment.

Wird mein cron-Ausdruck irgendwohin gesendet?

Nein. Parsing und Erklärung laufen vollständig in Ihrem Browser via JavaScript. Eingefügte Ausdrücke überqueren nie das Netzwerk, überprüfen Sie es im Netzwerk-Tab der DevTools, während Sie auf Erklären klicken. Sicher für cron-Ausdrücke in produktiven CI-Konfigurationen, Infrastrukturcode und operativen Runbooks, in denen der Zeitplan selbst sensibel sein kann (z. B. nächtliche Datenbank-Export-Schedules, die Wartungsfenster andeuten).

Verwandte Tools