Crontab Generator & Cron-Ausdruck Builder

Was ist ein Cron-Ausdruck?

# Linux crontab entry — runs every 15 minutes
*/15 * * * *  /usr/local/bin/poll-api.sh

# Kubernetes CronJob — weekdays at 9:00 AM UTC
apiVersion: batch/v1
kind: CronJob
metadata:
  name: daily-report
spec:
  schedule: "0 9 * * 1-5"
  timeZone: "UTC"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: report
              image: report-runner:1.0
          restartPolicy: OnFailure

# GitHub Actions workflow — hourly
on:
  schedule:
    - cron: '0 * * * *'

# AWS EventBridge — first of each month
ScheduleExpression: cron(0 0 1 * ? *)
# (Note: AWS uses the Quartz 6-field form with '?' for day-of-week)

Hauptfunktionen

Cron-Varianten & Scheduler

Beispiele für Cron-Ausdrücke

*/15 * * * *

0 9 * * 1-5

0 0 1 * *

*/5 9-17 * * 1-5

0 0 1 JAN,APR,JUL,OCT *

0 0 1 * 5

30 2 * * *

@daily

Wie man einen Cron-Ausdruck baut

1. 1

   Cron-Ausdruck eintippen oder einfügen

   Geben Sie einen Fünf-Feld-Cron-Ausdruck in das obige Eingabefeld ein (z. B. `*/15 * * * *`). Das Tool parst und validiert während des Tippens — grüner Haken für gültig, roter Fehler mit Feldname für ungültig. Makros wie `@daily`, `@hourly` etc. werden ebenfalls akzeptiert.

2. 2

   Oder die fünf Feldeingaben anpassen

   Sie müssen sich die Feldreihenfolge nicht merken — bearbeiten Sie Minute, Stunde, Tag des Monats, Monat oder Wochentag einzeln über die beschrifteten Eingaben. Der vollständige Ausdruck oben aktualisiert sich automatisch. Verwenden Sie `*` für Platzhalter, `*/N` für Schritte, `a-b` für Bereiche und `1,3,5` für Listen.

3. 3

   Eine Voreinstellung als Startpunkt wählen

   Tippen Sie einen beliebigen Preset-Chip an (Alle 15 Minuten, Werktags um 9 Uhr usw.), um einen gängigen Zeitplan zu laden, und passen Sie dann die Felder an Ihren genauen Bedarf an. Elf Voreinstellungen decken die Muster ab, die Sie in der Produktion tatsächlich nutzen werden.

4. 4

   Vorschau der nächsten Läufe prüfen

   Sehen Sie sich die fünf anstehenden Lauf-Datumsangaben an — wechseln Sie zwischen Lokal und UTC, um zu bestätigen, dass der Zeitplan feuert, wenn Sie es beabsichtigen. Das ist die zuverlässigste Methode, um die POSIX-Tag-des-Monats-/Wochentags-OR-Falle abzufangen, bevor sie Sie in der Produktion erwischt.

5. 5

   Kopieren und in Ihren Scheduler einfügen

   Klicken Sie auf Kopieren, um den Ausdruck zu übernehmen. Fügen Sie ihn in Ihre crontab, Ihren systemd-Timer, das `cron:` in GitHub Actions, AWS EventBridge, das `schedule` eines Kubernetes CronJob oder einen beliebigen cron-kompatiblen Scheduler ein. Vergessen Sie nicht, die Zeitzone des Ziel-Schedulers zu überprüfen — siehe den Abschnitt Best Practices unten.

Häufige Cron-Fehler

# Beabsichtigt: „erster Freitag des Monats"
0 0 1-7 * 5
# Tatsächlich: feuert an Tagen 1-7 des Monats ODER an jedem Freitag — beide Bedingungen

# Wrapper für echte AND-Semantik verwenden
0 0 * * 5  [ $(date +\%d) -le 7 ] && /your-script
# ODER eine Bedingung weglassen und den lockereren Zeitplan akzeptieren

# Geschrieben von US-East-Dev, deployt auf UTC-Server
0 9 * * *  /your-report.sh
# Feuert um 09:00 UTC = 04:00 US East — nicht, was der Dev meinte

# Zeitzone fixieren oder explizit in UTC schreiben
CRON_TZ=America/New_York
0 9 * * *  /your-report.sh

# Beabsichtigt: alle 15 Minuten
15 * * * *
# Tatsächlich: einmal pro Stunde, zur Minute 15 (4 Läufe/Stunde weniger als beabsichtigt)

# Korrekt
*/15 * * * *
# Alle 15 Minuten: Minute 0, 15, 30, 45 jeder Stunde

# Quartz-6-Feld in Linux-crontab kopiert
0 0 9 * * 1-5
# Linux liest: Minute=0, Stunde=0, dom=9, Monat=*, dow=1-5
# = Mitternacht an Tagen 9 in Monaten mit passendem Wochentag — Chaos

# POSIX-5-Feld, Sekunden weglassen
0 9 * * 1-5
# = werktags um 09:00 Uhr

# 30. oder 31. Februar — läuft nie
0 0 30 2 *
0 0 31 2 *
# Parst, aber kein Zeitplan feuert je

# Muster „letzter Wochentag im Februar" per Skript
0 0 28-29 2 *  [ $(date -d tomorrow +\%m) = 03 ] && /your-script

# Quartz: „letzter Freitag des Monats" — in POSIX ungültig
0 0 ? * 6L *

# POSIX-Wrapper-Skript-Ansatz für letzten Freitag
0 0 25-31 * 5  /your-script
# Läuft freitags zwischen dem 25. und 31. eines beliebigen Monats

Häufige Anwendungsfälle

Linux-crontab-Jobs

Erstellen und verifizieren Sie Einträge für `/etc/crontab`, `/etc/cron.d/*` oder benutzerspezifische `crontab -e`-Dateien. Verwenden Sie die Vorschau der nächsten Läufe, um vor dem Speichern zu bestätigen, dass der Zeitplan in der konfigurierten Zeitzone Ihres Servers zur richtigen Zeit landet.

Kubernetes-CronJob-Zeitpläne

Erzeugen Sie das Feld `spec.schedule` für einen Kubernetes CronJob. Kubernetes 1.27+ unterstützt außerdem `spec.timeZone` — nutzen Sie den UTC-Toggle, um Ihren Zeitplan in UTC zu entwerfen, und setzen Sie dann `timeZone` explizit, um die lokale Zeit des Worker-Nodes zu umgehen.

Geplante GitHub-Actions-Workflows

Bauen Sie den `cron:`-Eintrag unter `on.schedule`. GitHub Actions läuft immer in UTC — schalten Sie die Vorschau auf UTC um, um Ihren Zeitplan zu bestätigen. Vermeiden Sie Intervalle kürzer als 15 Minuten; der Scheduler von GitHub überspringt Kurzintervalljobs unter Last.

AWS-EventBridge-Regeln

Komponieren Sie den Cron-Ausdruck für eine geplante EventBridge-Regel. Hinweis: AWS verwendet die Quartz-artige Sechs-Feld-Syntax mit `?` für den Wochentag — dieses Tool liefert POSIX-Fünf-Feld, das Sie umwandeln müssen, indem Sie Sekunden (`0`) voranstellen und das `*` in einem der beiden Tag-Felder durch `?` ersetzen.

Geplante GitLab-CI-Pipelines

Verifizieren Sie den Cron-Ausdruck für eine geplante CI-Pipeline in GitLab. GitLab verwendet POSIX-Fünf-Feld-Syntax — also das, was dieses Tool ausgibt — und einen UI-Datumspicker, aber das Cron-Formular gibt Ihnen feinere Kontrolle für nicht-standardmäßige Intervalle.

Cloudflare Workers Cron Triggers

Bauen Sie den `[triggers.crons]`-Eintrag in `wrangler.toml`. Cloudflare verwendet POSIX-Fünf-Feld-Syntax. Minimales Intervall ist eine Minute; der Worker läuft in UTC. Verwenden Sie die Vorschau, um zu prüfen, dass der Trigger innerhalb Ihres erwarteten Fensters feuert.

Node.js-node-cron-Zeitpläne

Erstellen Sie Ausdrücke für die Bibliothek `node-cron`, die sowohl POSIX mit fünf Feldern als auch ein optionales vorangestelltes Sekundenfeld unterstützt. Bleiben Sie bei fünf Feldern, es sei denn, Sie benötigen ausdrücklich Sub-Minuten-Präzision — Sechs-Feld-Ausdrücke lassen sich nicht in Linux-crontab portieren.

Code-Review und Dokumentation

Fügen Sie einen Cron-Ausdruck aus einem PR oder Runbook ein, um sofort zu sehen, was er tut — kein Rätselraten mehr bei `30 7 * * 1-5` und kein Herauskramen einer Referenzkarte. Die Klartextbeschreibung eignet sich auch hervorragend für Inline-Kommentare und README-Dateien.

Cron-Syntax-Referenz

Feldreihenfolge: M H D M W

Minute (0-59), Stunde (0-23), Tag des Monats (1-31), Monat (1-12), Wochentag (0-6, 7 = ebenfalls Sonntag). Eselsbrücke: „My Hat Doesn't Match Wendy's". Das Wochentagsfeld akzeptiert sowohl numerische (0-6) als auch benannte Tokens (SUN-SAT, Groß-/Kleinschreibung egal).

Operatoren

`*` = beliebiger Wert; `,` = Listentrenner (`1,3,5`); `-` = Bereich (`1-5`); `/` = Schritt (`*/15`, `5/10`); Namen: JAN-DEC für Monat, SUN-SAT für Wochentag (Groß-/Kleinschreibung egal).

Makros (Aliase)

`@yearly` = `0 0 1 1 *`; `@annually` = `0 0 1 1 *`; `@monthly` = `0 0 1 * *`; `@weekly` = `0 0 * * 0`; `@daily` = `0 0 * * *`; `@midnight` = `0 0 * * *`; `@hourly` = `0 * * * *`. `@reboot` ist ein spezielles Nicht-Schedule (läuft nur beim Booten) und wird mit einer erklärenden Fehlermeldung abgelehnt.

POSIX-Tag-Semantik (OR-Regel)

Wenn SOWOHL Tag des Monats ALS AUCH Wochentag eingeschränkt sind (keines ist `*`), läuft der Zeitplan, wenn EINES VON BEIDEN zutrifft — OR-Semantik. Wenn nur eines eingeschränkt ist, entscheidet dieses. Sind beide `*`, passt jeder Tag. Diese OR-Regel gilt für vixie cron, BSD cron und die meisten POSIX-Implementierungen; Quartz nutzt `?`, um AND vs. OR zu disambiguieren.

Sechs-Feld-Modus (Quartz-Lite)

Wenn Ihre Eingabe sechs durch Leerzeichen getrennte Tokens hat, behandelt das Tool das erste als Sekundenfeld (0-59). Nützlich für Quartz, Spring `@Scheduled(cron=...)` und node-cron. NICHT portabel zu Linux-crontab oder POSIX-Schedulern — sie würden Ihre Sekunden als Minuten interpretieren und alles um eine Position verschieben.

Verankerung des Schrittoperators

`*/N` ist am niedrigsten Wert des Feldes verankert: `*/15` in Minute = `0,15,30,45`, nicht „alle 15 ab jetzt". Mit einer Basis ohne Platzhalter: `5/15` in Minute = `5,20,35,50`. Schrittwerte, die den Feldbereich nicht gleichmäßig teilen, überspringen am Rollover — das ist korrekt, kein Bug.

Validierungsgrenzen

Minute ∈ [0,59], Stunde ∈ [0,23], Tag des Monats ∈ [1,31], Monat ∈ [1,12], Wochentag ∈ [0,7]. Werte außerhalb des Bereichs erzeugen einen feldspezifischen Fehler. Der Tag des Monats wird NICHT gegen den Monat validiert (`0 0 31 2 *` parst problemlos, trifft aber nie zu, weil Februar keinen 31. hat — die Vorschau der nächsten Läufe zeigt „Keine anstehenden Läufe").

Quartz-Operatoren werden abgelehnt

POSIX-cron unterstützt Quartz' `?` (kein bestimmter Wert), `L` (letzter), `W` (nächstgelegener Wochentag) oder `#` (n-ter Wochentag) nicht. Dieses Tool lehnt sie mit einer klaren „Quartz operators not supported"-Meldung ab, statt sie stillschweigend als ungültiges POSIX zu parsen. Für Quartz-Zeitpläne verwenden Sie stattdessen ein Quartz-bewusstes Tool oder den Spring-Scheduler.

Jahresgrenze bei der Suche nach dem nächsten Lauf

Die Berechnung des nächsten Laufs sucht bis zu 4 Jahre nach vorne; Ausdrücke, die seltener als das zutreffen (z. B. Muster „29. Februar"), zeigen „Keine anstehenden Läufe in den nächsten 4 Jahren". Das ist beabsichtigt, um unbegrenzte Iteration auf unmöglichen Mustern zu vermeiden.

Best Practices für Cron-Zeitpläne

UTC auf Servern verwenden, zur Anzeigezeit umrechnen

Setzen Sie Ihre Server auf UTC (`/etc/timezone` oder `TZ=UTC`) und schreiben Sie alle Cron-Ausdrücke in UTC. Rechnen Sie erst zur Anzeigezeit in Ihren Dashboards und Berichten in die lokale Zeit um. Das eliminiert eine ganze Kategorie von Zeitzonen-Bugs, die bei Sommerzeit-Wechseln am härtesten zuschlagen, wenn Zeitpläne in lokaler Zeit stillschweigend doppelt feuern oder einen Lauf überspringen. Verwenden Sie den UTC-Toggle in diesem Tool, um Ihren Zeitplan von Anfang an in UTC zu entwerfen.

POSIX-Tag-des-Monats/Wochentag-OR-Falle vermeiden

Schränken Sie niemals sowohl Tag des Monats ALS AUCH Wochentag ein, es sei denn, Sie wollen OR-Semantik. Wenn Sie „jeden Montag im Januar" wollen, schreiben Sie `0 0 * 1 1` (Tag des Monats ist `*`); wenn Sie „den 1. jedes Monats" wollen, schreiben Sie `0 0 1 * *` (Wochentag ist `*`). Die POSIX-OR-Regel bewirkt, dass `0 0 1 * 1` am 1. UND an jedem Montag läuft — fast sicher nicht das, was Sie beabsichtigt haben. Die Vorschau der nächsten Läufe fängt das ab, wenn Sie vor dem Deployment prüfen.

Zeitzone des Zeitplans explizit fixieren

Moderne Scheduler unterstützen das Fixieren der Zeitzone in der Zeitplandefinition: `CRON_TZ=America/New_York` am Anfang einer crontab (vixie cron 3.0+), `spec.timeZone: "America/New_York"` für Kubernetes CronJobs 1.27+, Schedule-Ausdruck mit `ScheduleExpressionTimezone` für AWS EventBridge Scheduler. Fixieren Sie die Zeitzone explizit, statt sich auf den Standard des Servers zu verlassen — Server-Zeitzonen können sich bei Infrastruktur-Migrationen ohne Vorwarnung ändern.

Last über Minuten verteilen, nicht auf :00

Vermeiden Sie `0 * * * *` (jede Stunde zur Minute 0) für unkritische Jobs — im großen Maßstab erzeugt das Planen vieler Dinge exakt zur Minute :00 Lastspitzen. Wählen Sie einen zufälligen Minuten-Offset (`23 * * * *`, `41 * * * *`) für jeden Job, um die Last zu verteilen. Dasselbe gilt für tägliche Jobs: `30 3 * * *` ist für Ihre Datenbank freundlicher als `0 3 * * *`, wenn viele Jobs auf 03:00 zusammenlaufen.

Jobs idempotent machen

Cron hat keinen eingebauten Retry, keine Überlappungsverhinderung, keine Wiederherstellung verpasster Läufe. Ihr Job sollte mehrfach ausgeführt werden können (idempotent) und sich selbst prüfen. Statt „Bericht um 9 Uhr verschicken" entwerfen Sie ihn als „heutigen Bericht verschicken, falls noch nicht verschickt" — das heilt sich selbst nach Ausfallzeiten, versehentlichen doppelten Zeitplänen und gleichzeitigen Läufen. Idempotenz ist eine Eigenschaft des Jobs, nicht des Schedulers, und sie ist die wichtigste Zuverlässigkeitspraxis.

Heartbeat für kritische Zeitpläne hinzufügen

Der stille Fehlermodus von cron ist seine größte Schwäche — wenn der Zeitplan nicht feuert, sagt Ihnen nichts Bescheid. Lassen Sie bei kritischen Jobs den Job am Ende jedes Laufs einen Heartbeat-Dienst (Healthchecks.io, Cronitor, Dead Man's Snitch) anpingen; der Dienst alarmiert Sie, wenn der erwartete Ping ausbleibt. Das erfasst sowohl das Scheitern des Jobs als auch das Fehlfeuern des Zeitplans selbst. Der kostenlose Tarif deckt die meisten persönlichen und kleinen Team-Anforderungen ab.

Mit der Vorschau der nächsten Läufe vor dem Ausrollen verifizieren

Bevor Sie einen neuen Cron-Zeitplan deployen, sehen Sie sich die fünf anstehenden Lauf-Datumsangaben in der Vorschau dieses Tools an. Wechseln Sie zwischen Lokal und UTC. Bestätigen Sie, dass der Zeitplan landet, wenn Sie es beabsichtigen — nicht fünf Minuten zu früh, nicht am falschen Tag, nicht unter Auslassung des Wochenendes, das Ihnen wichtig war. Die Vorschau ist der billigste denkbare Produktionstest.

Häufig gestellte Fragen