Cron-Generator & Cron-Parser

Ausdruck eingeben und sofort lesen, wann er läuft – oder ihn Feld für Feld zusammenklicken. Dazu die nächsten Ausführungszeiten, damit du vor dem Deploy siehst, ob der Plan wirklich das tut, was du meinst. Alles lokal in deinem Browser.

Die fünf Felder eines Cron-Ausdrucks

Ein klassischer Crontab-Eintrag besteht aus fünf durch Leerzeichen getrennten Feldern, immer in dieser Reihenfolge: Minute (0–59), Stunde (0–23),Tag des Monats (1–31), Monat (1–12) undWochentag (0–6, wobei 0 der Sonntag ist – die 7 ist als zweiter Name für den Sonntag ebenfalls erlaubt).

┌───────── Minute (0–59)
│ ┌─────── Stunde (0–23)
│ │ ┌───── Tag des Monats (1–31)
│ │ │ ┌─── Monat (1–12)
│ │ │ │ ┌─ Wochentag (0–6, Sonntag = 0)
│ │ │ │ │
* * * * *

In jedem Feld sind vier Schreibweisen erlaubt: * für „jeder Wert“, eine Liste (1,15,30), ein Bereich (1-5) und eine Schrittweite (*/15 für alle 15 Einheiten, 1-9/2 für jeden zweiten Wert im Bereich). In den Feldern für Monat und Wochentag funktionieren auch die englischen Kurznamen, alsoJAN–DEC und SUN–SAT.

Die Falle mit Tag des Monats und Wochentag

Der mit Abstand häufigste Cron-Irrtum: 0 0 1 * MON läuft nicht am ersten Montag des Monats. Sind beide Tagesfelder eingeschränkt, verknüpft Cron sie mitODER – der Auftrag läuft an jedem Ersten des Monats und zusätzlich an jedem Montag. Nur wenn eines der beiden Felder auf * steht, zählt allein das andere. Dieses Werkzeug weist eigens darauf hin, sobald der eingegebene Ausdruck in diese Falle läuft.

Kurzformen mit @

Vixie-Cron kennt Abkürzungen für die üblichen Rhythmen: @yearly (=@annually, entspricht 0 0 1 1 *), @monthly,@weekly, @daily (= @midnight) und @hourly. Ein Sonderfall ist @reboot: Das ist kein Zeitplan, sondern ein Ereignis – der Auftrag läuft einmalig beim Start des Cron-Dienstes, weshalb es dafür auch keine „nächsten Ausführungszeiten“ geben kann.

Wo derselbe Ausdruck anders gemeint ist

Die fünf Felder sind bei crontab, GitHub Actions undKubernetes CronJobs identisch – ein Ausdruck lässt sich also übertragen. Zwei Unterschiede sind trotzdem wichtig: GitHub Actions rechnet grundsätzlich in UTC, und bei Kubernetes hängt es von der optionalen timeZone-Angabe ab. Ein0 3 * * * läuft dort also nicht zwangsläufig um drei Uhr Ortszeit.

Der Quartz-Scheduler aus der Java-Welt verwendet dagegen sechs oder sieben Felder – mit Sekunden am Anfang und einem optionalen Jahr am Ende – und kennt zusätzliche Sonderzeichen wie L (letzter Tag), W (nächster Werktag) und# (n-ter Wochentag im Monat). Dieses Werkzeug bildet bewusst den klassischen Fünf-Feld-Syntax ab und lehnt Quartz-Erweiterungen mit einer Fehlermeldung ab, statt sie still falsch auszulegen.

Häufige Fragen

In welcher Zeitzone sind die angezeigten Termine?
In der deines Browsers – sie steht über der Liste. Auf dem Zielsystem gilt dessen eigene Zeitzone, und genau daraus entsteht der Klassiker „der Job lief eine Stunde zu früh“. Prüfe im Zweifel timedatectl auf dem Server bzw. die timeZone-Angabe deines CronJobs.

Warum bekomme ich für manche Ausdrücke keine Termine?
Weil es keine gibt. 0 0 30 2 * verlangt den 30. Februar – ein Datum, das nie eintritt. Die Suche reicht fünf Jahre in die Zukunft; findet sie in diesem Zeitraum nichts, sagt das Werkzeug das ausdrücklich, statt eine leere Liste zu zeigen.

Was bedeutet */15 genau?
„Jeder 15. Wert, beginnend beim kleinsten“ – im Minutenfeld also 0, 15, 30 und 45. Wichtig: Die Schrittweite bezieht sich immer auf den Bereich des Feldes, nicht auf die zuletzt abgelaufene Zeit. */40 im Minutenfeld ergibt deshalb 0 und 40 und danach eine Lücke von 20 Minuten, nicht etwa alle 40 Minuten gleichmäßig.

Werden meine Eingaben hochgeladen?
Nein. Parser, Klartext-Übersetzung und Terminberechnung sind reines JavaScript in deinem Browser – es gibt keinen Server, der etwas entgegennehmen könnte. Gemerkt wird nur, ob du zuletzt im Lese- oder im Baumodus warst und wie viele Termine du angezeigt bekommst.