# Crontab-Generator

URL: https://www.toolflux.app/crontab-generator/
Stand: 2026-05-19

Cron-Ausdruck eintippen und gegen Vixie, Quartz, AWS EventBridge, GitHub Actions und Kubernetes prüfen. Mit Klartext-Erklärung und Diagnostics für die bekannten Footguns.

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.

| Eigenschaft | Vixie/Linux | AWS EventBridge |
| --- | --- | --- |
| Feld-Anzahl | 5 | 6 (mit Jahr-Feld am Ende) |
| Tag-der-Woche-Indizierung | 0-6, Sonntag = 0 | 1-7, Sonntag = 1 |
| DOM-OR-DOW | beide Felder gleichzeitig erlaubt | genau eines muss `?` sein |
| Zeitzone | lokale Server-TZ | Scheduled Rules nur UTC; EventBridge Scheduler unterstützt IANA-Zonen separat zum Cron-Ausdruck |

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.

### FAQ

**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.