Crontab-Generator mit Multi-Flavor-Compile und Gotcha-Warnungen

Ein Crontab-Generator beantwortet zwei Fragen gleichzeitig: was dein Ausdruck im Klartext bedeutet - und ob er auf den Plattformen ankommt, an die du ihn schickst. Toolflux schaltet fünf Flavors parallel: Vixie/Linux, Quartz, AWS EventBridge, GitHub Actions und Kubernetes. Die Kompatibilitäts-Matrix zeigt pro Ziel, ob dein Ausdruck legal-äquivalent läuft, anders ausgelöst wird oder direkt abgelehnt wird.

Was bedeutet 0 0 15 * 5 in Cron?

0 0 15 * 5 läuft unter Vixie/Linux am 15. eines jeden Monats UND zusätzlich an jedem Freitag - nicht nur an Freitagen, die auf den 15. fallen. Cron verknüpft Tag-im-Monat (DOM) und Tag-der-Woche (DOW) mit ODER, sobald beide Felder gesetzt sind. Aus „der 15., wenn Freitag" wird so „rund 62-63 Mal pro Jahr" (52 Freitage plus 12 Fünfzehnte minus den ein bis zwei Überlapptagen).

Die Falle ist berüchtigt, weil POSIX-Cron sich an dieser Stelle bewusst von der Bauchgefühl-Logik unterscheidet. Möchtest du ausschließlich Freitag-den-15. treffen, brauchst du eine Shell-Bedingung im Job-Skript, nicht den Cron-Ausdruck. Die Diagnostics-Strip im Tool blendet die Warnung automatisch ein, sobald DOM und DOW gleichzeitig eingeschränkt sind und du im Vixie-, GitHub-Actions- oder Kubernetes-Flavor bist.

Quartz und AWS EventBridge verhalten sich anders: sie verlangen, dass eines der beiden Felder ? ist, und kennen die ODER-Regel deshalb gar nicht. Genau dort beginnen viele der „mein Schedule fährt unter AWS anders"-Threads.

Warum läuft mein GitHub-Actions-Cron nicht?

Drei häufig dokumentierte Gründe stecken hinter den stillen Aussetzern bei GitHub Actions. Jeder davon wird in der Diagnostics-Strip einzeln markiert, sobald du den Flavor auf GitHub Actions stellst. Es ist nie nur „mein Cron ist kaputt" - es ist meist einer dieser drei.

• Führende Null in numerischen Feldern (08 statt 8). Vixie-Cron und viele Online-Validatoren akzeptieren beides klaglos; Community-Berichten zufolge kann der Workflow in GitHub Actions daraufhin still deaktiviert werden, ohne dass eine Fehlermeldung im UI erscheint - die offiziellen Docs schweigen dazu. Schreib 8, nie 08.
• Volle Stunde unter Last. Workflows, die exakt zur vollen Stunde laufen sollen, werden bei Plattform-Last verzögert oder fallen ganz aus. Eine andere Minute als 0 zu wählen verringert das Risiko - GitHub empfiehlt das selbst in den on.schedule-Docs.
• Nur im Default-Branch wirksam. Cron-Trigger greifen nur, wenn die workflow.yml im Default-Branch (meist main) liegt. Auf einem Feature-Branch ist die Datei dekorativ.

Die Zeitzone ist die vierte stille Stolperstelle: GitHub Actions plant Schedule-Trigger standardmäßig nach UTC. Der Zeitzonen-Selector im Tool rechnet die nächsten Läufe lokal um, damit du den Versatz siehst - GitHubs eigene Engine bleibt für den on.schedule-Event bei UTC, sofern du dort nichts explizit anderes festlegst.

Wie unterscheidet sich AWS EventBridge von Linux Cron?

AWS EventBridge sieht aus wie Cron, ist aber an vier Stellen anders genug, dass eine 1:1-Übernahme aus einer crontab-Zeile zuverlässig schiefgeht. Die Kompatibilitäts-Matrix übersetzt automatisch und markiert die Stellen, an denen sich das Auslöseverhalten ändert. Lies die Zeile als Erklärung, nicht als Anweisung - die Korrektur ist schon im Snippet daneben.

Ein häufiger Importfehler steckt im DOW-Versatz: derselbe numerische Wert 5 heißt unter Linux Freitag, unter AWS Donnerstag. Wenn du eine bestehende Linux-Zeile nach AWS portierst und stumpf den Wert kopierst, läuft dein Job einen Tag zu früh - bis du dich darüber wunderst, dass die Bestätigungs-E-Mail an einem anderen Wochentag eintrifft als geplant.

Wofür steht */5 im Cron-Ausdruck?

*/5 im Minuten-Feld heißt nicht „immer dann, wenn die Minute durch 5 teilbar ist". Es heißt „beginne bei der unteren Grenze des Feldes und iteriere in 5er-Schritten". Bei Minuten ist die untere Grenze 0, also fällt das Ergebnis zufällig mit der Modulo-Interpretation zusammen. Bei anderen Feldern fällt es auseinander.

Praktischer Unterschied an einem Beispiel:

1. Minuten: */5 ergibt 0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55. Mit der Modulo-Logik gerechnet käme dasselbe heraus - hier sind beide Lesarten deckungsgleich.
2. Stunden mit Versatz: 5/5 im Stunden-Feld ergibt 5, 10, 15, 20. Nicht 0, 5, 10, 15, 20 - der Start liegt bei 5, nicht bei 0.
3. Tage im Monat: */5 im DOM-Feld ergibt 1, 6, 11, 16, 21, 26, 31 - die untere Grenze ist 1, nicht 0. Den 31. gibt es nicht in jedem Monat, was im Februar genau eine Iteration kostet.

Wenn du Schritte mit Versatz brauchst, schreib start/step explizit (5/15 statt */15 plus mentale Korrektur). Die Diagnostics-Strip flaggt keine Schritt-Logik direkt, aber die Nächste-Läufe-Liste macht den Versatz sichtbar: stehen die Minuten nicht da, wo du sie erwartest, ist meistens dieser hier die Ursache.

Häufige Fragen

Welche Flavors deckt das Tool ab?

Fünf: Vixie/Linux (5 Felder, der POSIX-Klassiker), Quartz (6 oder 7 Felder mit Sekunden und optionalem Jahr, das Java-Quartz-Scheduler-Format - Spring @Scheduled hat eine eigene, nicht-kompatible Cron-Syntax), AWS EventBridge (6 Felder, ?-Pflicht, standardmäßig UTC), GitHub Actions (5 Felder, standardmäßig UTC, mit mehreren Eigenheiten rund um Trigger und Drop-Verhalten) und Kubernetes CronJob (5 Felder, POSIX). Du wählst den Quell-Flavor oben - die Kompatibilitäts-Matrix rechnet automatisch in die anderen vier um. Abgedeckt ist die gängige Syntax (Zahlen, Bereiche, Schritte, Listen, Namen, * und ?); die Quartz-Erweiterungen L, W, # und Jahre jenseits 2099 sind heute noch nicht unterstützt.

Was bedeutet das ? in einem AWS- oder Quartz-Ausdruck?

? heißt „nicht spezifiziert" und ist nur im Tag-im-Monat- oder Tag-der-Woche-Feld erlaubt. Beide Flavors verbieten, dass beide Felder gleichzeitig eingeschränkt sind - du gibst entweder einen DOM-Wert und ? für DOW an, oder umgekehrt. Vixie/Linux kennt das ? nicht; dort dürfen beide Felder gleichzeitig Werte tragen, und die DOM-OR-DOW-Regel greift.

Warum ändert sich mein Ausdruck, wenn ich den Flavor umschalte?

Beim Umschalten kompiliert das Tool den aktuellen Ausdruck automatisch in die Syntax des Ziel-Flavors. Geht das verlustfrei (z. B. Vixie zu Kubernetes), bleibt die Semantik identisch. Geht es nicht (z. B. Quartz mit Sekunden zu Vixie ohne Sekunden), fällt das Tool auf den Standard-Ausdruck des Ziel-Flavors zurück, damit du nie auf einer „Ausdruck ungültig"-Fehlerseite landest.

In welcher Zeitzone werden die nächsten Läufe angezeigt?

Default ist die Browser-Zeitzone. Du kannst über das Zeitzonen-Feld jede IANA-Zone setzen (z. B. Europe/Berlin, America/New_York, Asia/Tokyo), und die Nächste-Läufe-Liste rechnet entsprechend um. Die zugrundeliegende Schedule-Logik selbst bleibt davon unberührt - sie zeigt nur die Anzeige um. AWS EventBridge und GitHub Actions planen auf der Plattform selbst standardmäßig in UTC; die Zeitzonen-Wahl hier ist eine Anzeige-Hilfe, kein Override für die Engine drüben.