Was ist ein Cron-Ausdruck?

Ein Cron-Ausdruck ist eine Zeitplan-Syntax aus fünf oder sechs Feldern, die jedem Server-Job sagt, wann er laufen soll. Felder von links nach rechts: Minute, Stunde, Tag-des-Monats, Monat, Wochentag, bei Quartz und Spring zusätzlich Sekunden, bei AWS und Quartz optional ein Jahr. Sternchen heißen jede gültige Zeit, Schrägstrich plus Zahl steht für Schritt-Weite (zum Beispiel */15 für alle 15 Minuten).

Was bedeutet 0 9 * * 1?

Jeden Montag um 09:00 Uhr. Erstes Feld 0 ist die Minute, zweites Feld 9 die Stunde, drittes und viertes Feld * stehen für jeden Tag und jeden Monat, fünftes Feld 1 für Montag (Sonntag = 0). Der Builder schreibt diesen Ausdruck in der Klartext-Erklärung als Jeden Montag um 09:00 Uhr, direkt für Voice-Search lesbar.

Warum laufen Cron-Jobs in der Sommerzeit doppelt oder gar nicht?

Sommerzeit-Übergänge verschieben oder verdoppeln eine Stunde. Im Frühling springt die Uhr von 02:00 auf 03:00, ein Job mit 0 2 * * * wird an diesem Tag stillschweigend übersprungen. Im Herbst läuft die Uhr von 03:00 zurück auf 02:00, derselbe Job läuft an diesem Tag zweimal. AWS und systemd dokumentieren dieses Verhalten als gewollt. Der Builder zeigt die Warnung neben der Next-Run-Liste, sobald die Zeitzone DST kennt und die Stunde betroffen ist.

Was ist der Unterschied zwischen Unix-Cron und Quartz?

Unix-Cron hat fünf Felder ab Minute, Quartz hat sechs (mit Sekunden vorn) oder sieben (mit Jahr hinten). Quartz erlaubt das Sonderzeichen ? in Tag-des-Monats oder Wochentag, weil Quartz die beiden Tages-Felder gar nicht kombinieren kann und deshalb in genau einem von beiden ein ? verlangt. Dazu kommen bei Quartz eigene Tokens: L für den letzten Tag des Monats, LW für den letzten Werktag, 15W für den Werktag neben dem 15., 6L für den letzten Freitag und 6#3 für den dritten Freitag. Der Builder rechnet sie aus und listet die nächsten Termine dazu auf. Auch der Wochentag zählt bei Quartz anders als bei Unix, nämlich 1 bis 7 mit Sonntag als 1. Unix nimmt 0 bis 7, wobei 0 und 7 beide Sonntag sind.

Was bedeutet ? in einem Cron-Ausdruck?

Das Fragezeichen heißt kein bestimmter Wert und ist nur in Tag-des-Monats und Wochentag erlaubt. Es löst die OR-Falle: wenn beide Felder gesetzt sind, läuft Vixie-Cron bei Tag-des-Monats ODER Wochentag, systemd bei UND. AWS EventBridge verlangt deshalb genau ein Fragezeichen, entweder im Tag-des-Monats oder im Wochentag-Feld. Quartz und Spring erlauben es ebenfalls. Unix-Cron kennt das Fragezeichen nicht.

Welche Sonder-Tokens gibt es im Cron?

Die geläufigsten sind @yearly (0 0 1 1 *), @monthly (0 0 1 * *), @weekly (0 0 * * 0), @daily oder @midnight (0 0 * * *) und @hourly (0 * * * *). Sie sind Aliase auf die Fünf-Felder-Form und sparen das Zählen der Sterne. Unix-Cron und Spring kennen sie, Quartz und AWS EventBridge nicht. Der Builder expandiert sie in der Unix-Variante; in den anderen Varianten meldet er stattdessen, dass die Feldzahl nicht passt.

In welcher Zeitzone laufen GitHub-Actions-Cron-Schedules?

Standardmäßig in UTC, aber seit März 2026 nicht mehr zwangsläufig: GitHub Actions akzeptiert im on.schedule-Block einen timezone-Schlüssel neben cron, mit einer IANA-Zone wie Europe/Berlin. Ohne diesen Schlüssel gilt weiter UTC, unabhängig vom Repository-Standort oder der Runner-Region, und wer 0 9 * * 1 schreibt und auf 09:00 Berliner Zeit hofft, bekommt den Job um 11:00 Sommerzeit oder 10:00 Winterzeit. Der Builder schreibt den Schlüssel deshalb mit und legt die nach UTC umgerechnete Zeile als Kommentar darunter, für ältere GitHub-Enterprise-Server, die den Schlüssel noch nicht kennen.

Wie kommt der Cron-Ausdruck in mein Kubernetes-CronJob-Manifest?

Kubernetes-CronJob-Manifeste haben einen schedule-String im YAML-spec-Block, der exakt die Unix-Fünf-Feld-Form annimmt. Der Builder exportiert ein vollständiges Manifest mit apiVersion batch/v1, kind CronJob, metadata.name und einer busybox-Beispielcontainer-Spezifikation. Die gewählte Zeitzone landet als spec.timeZone im Manifest, sonst läuft der Job in der Zone des Clusters statt in deiner. Den Job-Namen kann man im Export-Tab setzen, der Builder bereinigt ihn auf DNS-1123 (Kleinbuchstaben plus Bindestriche), damit Kubernetes ihn akzeptiert.

Cron-Expression-Builder: Quartz, AWS, DST-Warnung

Was macht der Builder?

Der Cron-Expression-Builder ist ein Live-Editor für die vier dominanten Cron-Dialekte: klassischer Unix-Cron mit fünf Feldern, Quartz mit sechs oder sieben Feldern, AWS EventBridge mit fester Sechs-Feld-Form und Spring @Scheduled mit derselben Sechs-Feld-Form ohne Jahr. Tippst du in das Feld, übersetzt der Builder den Ausdruck sofort in einen deutschen Klartext-Satz, listet die nächsten fünf Ausführungen in deiner IANA-Zeitzone auf und meldet Sommerzeit-Übergänge, unmögliche Datumskombinationen und die OR-Falle, wenn Tag-des-Monats und Wochentag gleichzeitig gesetzt sind.

Unter der Erklärung steht, wie oft der Plan wirklich läuft: pro Lauftag, pro Monat und pro Jahr. * * * * * sind 525.600 Läufe im Jahr, im Schaltjahr 527.040. Wer pro Aufruf zahlt, sollte die Zahl vor dem Deploy gesehen haben. Wo der Kalender keine feste Zahl hergibt, steht eine Spanne mit Begründung statt einer erfundenen Zahl, denn Montage sind mal 52 und mal 53 im Jahr, und bei gesetztem Tag-des-Monats und Wochentag zählt die ODER-Verknüpfung beide Treffer mit. Ein Klick auf ein Feld zeigt dessen Bedeutung, den Wertebereich der gewählten Variante und die dort erlaubten Sonderzeichen. Ausdruck, Variante und Zeitzone stehen in der Adresse, ein geteilter Link öffnet also denselben Stand.

Pure-client. Jeder Ausdruck bleibt in deinem Browser. Kein Server, kein Tracking, keine Cookie-Wall. Das Tool funktioniert offline, sobald die Seite einmal geladen ist.

Warum braucht es ein Tool für Cron?

Cron sieht harmlos aus, fünf Sterne reichen, um jede Minute zu treffen. Aber sobald du etwas spezifischer wirst, beißen die Details. 0 0 31 2 * parst sauber als jeden 31. Februar um Mitternacht, läuft aber nie. 0 0 * * 0,1 läuft scheinbar nur Sonntag und Montag, auf systemd-Timern stimmt das, auf klassischen Vixie-Cron-Implementierungen verbindet das System die beiden Tag-Felder per ODER, und du erwischst doppelt so viele Tage wie gedacht. 0 2 * * * läuft 364 Tage im Jahr, und an dem einen Sonntag im März, an dem die Sommerzeit beginnt, läuft er nicht, weil 02:00 in vielen europäischen Zeitzonen schlicht nicht existiert. AWS EventBridge dokumentiert das hinter einem Absatz, der mit den Worten gewollt-übersprungen beginnt.

Der Builder fängt diese drei Klassen mit derselben Oberfläche: Klartext-Erklärung, Next-Run-Liste in deiner Zeitzone und ein Hinweis-Panel, das Sommerzeit, OR-Falle und unmögliche Daten in einer einheitlichen Sprache nennt.

Vier Dialekte in einem Editor

Unix-Cron ist die fünf-Felder-Form, die in jeder Linux-Distribution mitkommt. Quartz, der Scheduler hinter Spring-Batch und Quartz.NET, hängt vorne ein Sekunden-Feld an und hinten optional ein Jahres-Feld. Quartz zählt den Wochentag von 1 bis 7 mit Sonntag als 1, Unix von 0 bis 7, wobei sowohl 0 als auch 7 den Sonntag meinen. AWS EventBridge übernimmt die Quartz-Form samt dieser Zählung. Beide verlangen genau ein Fragezeichen in Tag-des-Monats oder Wochentag, sonst lehnt der Builder ab. Spring @Scheduled ist ein Quartz-Klon ohne Jahr, zählt den Wochentag aber wie Unix.

Der Builder unterscheidet die vier Dialekte über das obere Tab-Pickerfeld. Jeder Klick auf einen Preset (Stündlich, Werktags 09:00, Wochenende 10:00) zieht automatisch den passenden Ausdruck für die aktuell gewählte Variante. Ein Wechsel der Variante übersetzt einen Preset-Treffer mit, ohne dass du den Ausdruck erneut eingeben musst.

Klartext-Erklärung: Voice-Search-First

Die erste Zeile der Erklärung beantwortet die Frage direkt, Beispiel: Jeden Montag um 09:00 Uhr. Diese Konvention erleichtert Voice-Search und LLM-Citation: der Satz funktioniert als Schlagwort ohne weitere Kontext-Schritte. Google-Assistant- und Perplexity-Antworten lesen typischerweise die ersten zehn Wörter aus dem ersten Absatz vor, die Erklärung ist genau so geformt, dass das passt.

Zeitzonen-Vorschau

Die Next-Run-Liste rechnet im Hintergrund über Intl.DateTimeFormat und prüft je Kalendertag der Zielzone, ob Monat, Tag und Wochentag passen, bevor sie die Uhrzeiten dieses Tages matcht. Acht populäre Zeitzonen sind voreingestellt: UTC, Europa/Berlin, Europa/London, Amerika/New York und vier weitere. Die IANA-Zeitzonen-Datenbank ist die weltweite Referenz für Zeitzonen-Daten, Browser, Server und Runtime-Bibliotheken benutzen sie.

Sommerzeit-Warnung

Der Builder sucht die nächsten Zeitumstellungen der gewählten Zone, rund dreizehn Monate weit, und prüft für jede, ob eine geplante Uhrzeit in die verschluckte oder in die doppelte Spanne fällt. Nur dann erscheint eine Warnung neben der Next-Run-Liste, mit dem echten Sprung dieser Zone: Am 28.03.2027 fällt der Lauf um 02:30 aus, die Uhr springt von 02:00 auf 03:00 oder Am 25.10.2026 läuft der Job um 02:30 zweimal, die Uhr wird von 03:00 auf 02:00 zurückgestellt. Der Sprung wird gemessen, nicht angenommen: Pacific/Chatham stellt um 02:45, Australia/Lord_Howe um eine halbe Stunde, und genau das steht dann auch da. Diese Sätze verhindern die häufigste Fehlannahme bei Backup- und Reporting-Jobs.

Was prüft die semantische Validierung?

Syntaktisch gültig heißt nicht semantisch sinnvoll. Der Builder unterscheidet drei Klassen:

Wird nie laufen, 0 0 31 2 * parst sauber, aber der 31. Februar existiert nicht. Der Builder erkennt das anhand der Tabelle für Monats-Längen und meldet die Warnung sofort.
OR-Falle, Wenn Tag-des-Monats und Wochentag beide gesetzt sind, verbindet Vixie-Cron per ODER, systemd und Spring per UND. 0 0 1 * MON läuft auf Vixie-Cron jeden 1. plus jeden Montag, auf systemd nur am 1., wenn das ein Montag ist. Die Warnung nennt beide Implementations- Erwartungen, damit der Reviewer sich nicht später wundert.
Variantenfehler, Wer Sekunden in einem Unix-Cron tippt oder das Fragezeichen in einem Unix-Feld setzt, bekommt eine klare Variantenfehler-Meldung statt eines stillen Parse-Fails.

Welche Exporte sind eingebaut?

Vier Zielformate sind vorbereitet. Jedes liefert exakt den Block, den du in dein YAML, Manifest oder crontab kopieren kannst:

Jeder Export wird in den Dialekt des Ziels übersetzt, nicht bloß durchgereicht. Ein AWS-Ausdruck mit Fragezeichen und Jahres-Feld wird für die crontab auf fünf gültige Unix-Felder umgeschrieben, ein Unix-Ausdruck für EventBridge auf sechs Felder mit Fragezeichen. Was das Ziel nicht ausführen kann, kommt auskommentiert mit einer Begründung darüber, damit ein blindes Einfügen keinen kaputten Plan installiert.

crontab: eine reine Cron-Zeile plus Kommentar-Header und CRON_TZ für die gewählte Zone, so läuft der Job nicht in der Zeitzone des Servers. Eignet sich für crontab -e oder eine /etc/cron.d-Datei.
GitHub Actions: vollständiger on.schedule-Block mit name und cron in Single-Quotes. Die Uhrzeit bleibt deine Ortszeit, daneben steht der timezone:-Schlüssel, den GitHub Actions seit März 2026 versteht. Darunter als Kommentar dieselbe Zeile nach UTC umgerechnet, für ältere GitHub-Enterprise-Server ohne diesen Schlüssel; verschiebt die Umrechnung dort den Tag, wandert der Wochentag mit.
Kubernetes CronJob: vollständiges Manifest mit apiVersion: batch/v1, kind: CronJob, spec.timeZone für die gewählte Zone, sanitiziertem DNS-1123-Namen und busybox-Beispiel-Container. Du ersetzt nur image und command.
AWS EventBridge: cron(...)-Wrap in der Sechs-Feld-Form mit Jahr und Fragezeichen, die die AWS-Konsole verlangt.

Was ist absichtlich nicht gebaut?

Der Builder ist Builder-only: er plant, validiert und exportiert. Monitoring, Alerting, History und Cron-Job-Aufrufe gehören nicht hierher. Diese Funktionen sind absichtlich nicht gebaut:

Kein Monitoring oder Dead-Man’s-Switch, dafür gibt es Cronitor und ähnliche Dienste.
Kein History-Speicher länger als die aktuelle Session, der Hard-Cap kein localStorage gilt auch hier.
Keine Simulation länger als vier Jahre, 0 0 29 2 * würde sonst die Vorschau einfrieren.
Keine Vendor-Dialekte (Jenkins H-Hash, Nomad-spezifisch, Camel-Quartz-Extensions).
Keine NLP-Übersetzung Text-zu-Cron, das gehört in LLM-Tools und bricht das Pure-Client-Versprechen.

Wie ist die Privacy geregelt?

Der Builder läuft komplett in deinem Browser. Es gibt keinen Serveraufruf, kein Telemetrie-Endpunkt, keinen Cookie-Banner. Die einzigen Host-APIs, die der Builder benutzt, sind new Date() für die Anker-Zeit der Next-Run-Vorhersage und Intl.DateTimeFormat für die IANA-Zeitzonen-Umrechnung. Beide sind Web-Standards seit Jahren, ohne Tracking-Implikation.