Crontab Guru

Fügen Sie einen Cron-Ausdruck ein und erhalten Sie eine Feld-für-Feld-Erklärung auf einfachem Englisch. Keine Notwendigkeit, die Feldreihenfolge zu kennen oder Bereiche nachzuschlagen: der Guru geht jedes der fünf Felder durch (Minute, Stunde, Tag des Monats, Monat und Wochentag) und liest den Ausdruck von links nach rechts. Praktisch, um eine Crontab-Zeile vor der Bereitstellung zu prüfen oder eine übernommene Zeile zu erklären.

So verwenden Sie den Guru

  1. 1

    Fügen Sie den Ausdruck ein

    Kopieren Sie einen beliebigen Cron-Ausdruck mit 5 Feldern (zum Beispiel `0 9 * * 1-5`) in das Feld.

  2. 2

    Erklären lassen

    Klicken Sie auf "Explain Cron", und das Tool liefert eine zeilenweise Beschreibung jedes Felds: Minute, Stunde, Tag des Monats, Monat und Wochentag.

  3. 3

    Lesen Sie die Beschreibung

    Die Erklärung wird auf Englisch erzeugt, zum Beispiel "Minute: every 5 minutes" oder "Hour: from 9 through 17."

  4. 4

    Vor der Bereitstellung prüfen

    Nutzen Sie die Erklärung, um zu bestätigen, dass der Zeitplan das tut, was Sie wollen, bevor Sie ihn in Ihre Crontab, CI-Konfiguration oder ein Kubernetes-Manifest übernehmen.

Feld-Spickzettel

 ┌───────────── Minute (0-59)
 │ ┌─────────── Stunde (0-23)
 │ │ ┌───────── Tag des Monats (1-31)
 │ │ │ ┌─────── Monat (1-12 oder JAN-DEC)
 │ │ │ │ ┌───── Wochentag (0-6 oder SUN-SAT; So = 0 oder 7)
 │ │ │ │ │
 * * * * *

Operatoren in Cron-Ausdrücken

Operator Bedeutung Beispiel
* Jeder Wert * * * * *
, Liste von Werten 0,15,30,45
- Bereich 9-17
/ Schritt (Start/Schritt) */5, 0-30/5
L Letzter (Tag des Monats oder letzter Wochentag, Quartz) L, 5L
W Nächster Wochentag 15W (Quartz)
# N-ter Wochentag des Monats 1#3 (Quartz)
? Kein spezifischer Wert Nur Quartz

Die Reihenfolge des Lesens ist wichtig

0 */2 * * 1-5 liest sich von links nach rechts als: Minute 0, jede 2. Stunde, beliebiger Tag des Monats, beliebiger Monat, Montag bis Freitag. Menschen lesen die Felder aus Gewohnheit manchmal von rechts nach links und werden verwirrt. Beginnen Sie immer bei der Minute.

Die “alle X Minuten”-Falle

*/10 * * * * wird um Minute 0, 10, 20, 30, 40, 50 ausgeführt, nicht “alle 10 Minuten ab dem Zeitpunkt, an dem der Job erstellt wurde.” Cron-Schritte messen immer vom Anfang des Bereichs des Feldes. Wenn Sie einen Job um 12:03 starten, ist die erste Ausführung um 12:10, nicht um 12:13.

Für Jobs, die wirklich “N Minuten nach der letzten Ausführung” benötigen, verwenden Sie einen Scheduler mit einem persistenten Timer (systemd-Timer mit OnUnitActiveSec oder anwendungsseitige Planung mit einem gespeicherten Zeitstempel der letzten Ausführung).

Cron-Stolperfallen, die man kennen sollte

  • Tag des Monats + Wochentag beide gesetzt: die meisten Cron-Implementierungen behandeln das als ODER-Verhalten, wahrscheinlich nicht das, was Sie wollen.
  • Schritt von 0: */0 ist ungültig.
  • Bereich wickelt sich um: 22-2 für Stunden funktioniert im klassischen Cron nicht; verwenden Sie 22-23,0-2.
  • 30. Februar: ein Zeitplan wie 0 0 30 2 * wird niemals ausgeführt.
  • DST-Ambiguität: Jobs, die zwischen 2 und 3 Uhr geplant sind, können an DST-Übergangstagen zweimal oder gar nicht ausgeführt werden.

Cron vs. moderne Scheduler

Unix-Cron ist immer noch überall, aber für alles Kritische wollen Sie wahrscheinlich:

  • systemd-Timer: verpasste Ausführungen erfassen, randomisierte Offsets unterstützen, aus Unit-Dateien lesen.
  • Kubernetes CronJob: deklarativ, Wiederholungen, zeitzonenbewusst ab 1.25+.
  • Airflow / Prefect / Dagster: für Jobs mit Abhängigkeiten, Wiederholungen, Backfills und Beobachtbarkeit.
  • GitHub-Actions-Zeitplan: 5-Feld-Cron, nur UTC, Mindestintervall von 5 Minuten, Best-Effort-Zustellung.

Cron selbst ist ein großartiges Format, aber ein schlechter Scheduler für Jobs, die nicht verpasst werden dürfen.

Häufig gestellte Fragen

Weil der Wochentag 0 im Standard-Cron Sonntag ist (und 7 auch Sonntag ist, was beide Konventionen unterstützt). Montag ist 1. Quartz nummeriert Wochentage 1-7 mit Sonntag = 1, was häufig zu Verwirrung führt, wenn man zwischen Dialekten wechselt.

Klassisches Unix-Cron läuft in der lokalen Zeitzone des Servers, was auch immer /etc/timezone sagt. Kubernetes CronJob, GitHub Actions und die meisten Cloud-Scheduler laufen standardmäßig in UTC. Bestätigen Sie das immer und verwenden Sie, wenn möglich, UTC, um DST-Überraschungen zu vermeiden.

Klassisches Cron kann das nicht direkt ausdrücken. Umgehung: führen Sie jeden Montag aus und prüfen Sie das Datum im Skript: [ $(date +%d) -le 7 ] && ./job.sh. Quartz unterstützt das nativ mit 1#1.

Nein. Jeder Zeitplan benötigt seine eigene Zeile. Sie können aber mehrere Zeitpläne in einer Zeile mit Listen kombinieren: 0 9,17 * * * wird um 9 und 17 Uhr ausgeführt. Für Zeitpläne, die sich nicht als eine Zeile ausdrücken lassen, fügen Sie mehrere Zeilen hinzu, die auf denselben Befehl verweisen.

Verwandte Tools