Cron-Ausdrückungsbeispiele: 30 Zeitpläne erklärt (mit Fallstricke)

Cron hat seit den 1970er Jahren wiederkehrende Jobs auf Unix-Systemen geplant, und seine fünf-Feld-Syntax treibt jetzt Kubernetes CronJobs, GitHub Actions, Cloud-Scheduler wie AWS EventBridge und Google Cloud Scheduler, CI-Pipelines und unzählige Jobbibliotheken an. Die Syntax ist kompakt genug, um sich zu merken, aber subtil genug, dass die meisten Ingenieure mindestens einen Zeitplan ausgeliefert haben, der zur falschen Zeit lief. Dieser Leitfaden erläutert jeden Bereich und listet dann 30 praktische Ausdrücke mit Notizen zu den Fallen auf.

Die fünf Felder

┌───────────── minute (0–59)
│ ┌─────────── hour (0–23)
│ │ ┌───────── day of month (1–31)
│ │ │ ┌─────── month (1–12 or JAN–DEC)
│ │ │ │ ┌───── day of week (0–6 or SUN–SAT; 7 is also Sunday on most systems)
│ │ │ │ │
* * * * *

Jedes Feld akzeptiert:

• * jeder Wert.
• Eine Zahl 5 bedeutet genau 5.
• Eine Liste 1,15 bedeutet 1 und 15.
• Ein Bereich 9-17 bedeutet 9 bis einschließlich 17.
• Ein Schritt */15 bedeutet jeden 15. Wert ab dem Minimum; 10-50/20 bedeutet 10, 30, 50.

Ein Job läuft, wenn die aktuelle Zeit mit allen Feldern übereinstimmt, mit einer wichtigen Ausnahme, die unten beschrieben wird. Fügen Sie einen Ausdruck in einen [cron expression parser] ((/tools/cron-parser) ein, um eine einfache Beschreibung und die nächsten Ausführungszeiten zu sehen.

Alle N Minuten oder Stunden

1. * * * * * jede Minute.
2. */5 * * * * alle 5 Minuten (um :00,:05, :10 ...).
3. */15 * * * * alle 15 Minuten
4. 0,30 * * * * alle halbe Stunde, um eine halbe Stunde.
5. 7 * * * * jede Stunde um 7 Minuten. Wenn man eine ungerade Minute wählt, verbreitet sich die Last weg von der geschäftigen Spitze der Stunde.
6. 0 */2 * * * alle 2 Stunden, um 00:00, 02:00, 04:00 ...
7. 0 */6 * * * viermal täglich: 00:00, 06:00, 12:00, 18:00.
8. 15 8-18/2 * * * um 08:15, 10:15, 12:15, 14:15, 16:15 und 18:15.

Pitfall: Schritte starten an jeder Grenze neu. */7 im Minutenfeld feuert um 00:00, 00:07 ... 00:56 und dann wieder um 00:00, also ist die Lücke über die Stunde 4 Minuten, nicht 7. Wenn Sie ein echtes festes Intervall benötigen, das nicht durch 60 geteilt wird, verwenden Sie einen Zeitplaner, der Intervalle unterstützt, oder lassen Sie den Job selbst überprüfen.

Tägliche Zeitpläne

9. 0 0 * * * jeden Tag um Mitternacht.
10. 30 2 * * * jeden Tag um 02:30, ein klassisches Backup-Fenster.
11. 0 9,17 * * * um 09:00 und 17:00 Uhr täglich.
12. 0 12 * * * am Mittag.
13. 45 23 * * * um 23:45, kurz vor Mitternacht für die Tagesberichte.

Pitfall: Arbeitsplätze zwischen 01:00 und 03:00 Uhr Ortszeit können übersprungen oder zweimal bei Sommerzeitübergängen ausgeführt werden. Wenn Ihr Server eine Zone mit DST verwendet, planen Sie kritische Aufgaben außerhalb dieses Fensters oder führen Sie den Server in UTC aus.

Werktage und Wochenenden

14. 0 9 * * 1-5 09:00 Montag bis Freitag.
15. */10 9-17 * * 1-5 alle 10 Minuten während der Geschäftszeiten an Wochentagen (letzte Ausgabe um 17.50 Uhr).
16. 0 10 * * 6,0 10:00 am Samstag und Sonntag.
17. 0 8 * * MON 08:00 Uhr jeden Montag. Namen sind bei den meisten Implementierungen groß- und kleinführig.
18. 30 16 * * 5 Freitag um 16:30 Uhr.

Monatlich und jährlich

19. 0 0 1 * * Mitternacht am ersten Tag eines jeden Monats.
20. 0 6 15 * * 06:00 Uhr am 15. jeden Monats.
21. 0 0 1,15 * * am 1. und 15., üblich für die Gehaltsliste.
22. 0 0 1 1 * Mitternacht am 1. Januar.
23. 0 9 1 */3 * 09:00 Uhr am ersten Tag eines jeden Quartals (Januar, April, Juli, Oktober).
24. 0 0 L * * der letzte Tag des Monats. Hinweis: L ist eine Erweiterung, die von Quartz, einigen Cloud-Schedulern und einigen Bibliotheken unterstützt wird, aber nicht von klassischem Unix cron.
25. 0 22 28-31 * * kombiniert mit einem Check im Skript ([ "$(date -d tomorrow +%d)" = "01" ]) eine tragbare Möglichkeit, am letzten Tag des Monats mit Standard-Cron auszuführen.

Tag des Monats oder Tag der Woche?

26. 0 9 13 * 5 viele Leute lesen das als "Freitag den 13.". In klassischem Cron bedeutet es ** jeden 13. des Monats und jeden Freitag **. Wenn beide Tagefelder eingeschränkt sind (wie auch *), führen Vixie cron und seine Nachkommen den Job aus, wenn either übereinstimmt.

Um nur am Freitag den 13. zu laufen, planen Sie 0 9 13 * * und überprüfen Sie den Wochentag im Skript, oder verwenden Sie einen Planer mit expliziter AND-Semantik. Das ist die überraschendste Regel in Cron und eine, an die man sich erinnern sollte.

Spezielle Saiten

Viele Cron-Implementierungen akzeptieren Verknüpfungen:

27. @hourly ist gleich 0 * * * *.
28. @daily oder @midnight 0 0 * * *.
29. @weekly — 0 0 * * 0.
30. @reboot einmal beim Starten (nur für Unix cron; nicht in Kubernetes oder GitHub Actions verfügbar).

Plattformunterschiede

• Kubernetes CronJobs verwenden eine Standard-Syntax mit fünf Feldern. Seit Kubernetes 1.27 können Sie spec.timeZone: "Europe/Berlin" setzen; ansonsten folgen die Zeitpläne der Zone des Controller-Managers, die normalerweise UTC ist.
• GitHub-Aktionen-Zeitpläne laufen immer in UTC, können in Zeiten hoher Belastung verzögert werden, und das Mindestintervall beträgt 5 Minuten. Vermeiden Sie 0 * * * *, wenn Präzision wichtig ist; wählen Sie eine ungerade Minute.
• AWS EventBridge verwendet sechs Felder (minute hour day-of-month month day-of-week year) und erfordert ? in einem der beiden Tagfelder.
• **Quartz (Java) ** und Spring verwenden sechs oder sieben Felder mit Sekunden zuerst: 0 0 9 * * MON-FRI.
• systemd-Timer verwenden eine andere, lesbarere Syntax (OnCalendar=Mon..Fri 09:00) und verarbeiten verpasste Laufzeiten mit Persistent=true.

Bestätigen Sie immer, welchen Dialekt Ihre Plattform erwartet, bevor Sie einen Ausdruck kopieren.

Zeitzonen

Cron bewertet Ausdrücke in der Zeitzone des Planers. Ein Job, der von einem Entwickler in Tokio als 0 9 * * * geschrieben wurde, läuft um 09:00 UTC auf einem UTC-Server 18:00 in Tokio. Empfehlungen:

• Server und Zeitplaner in UTC ausführen und bei der Schreibung von Zeitplänen die vorgesehenen lokalen Zeiten in UTC umwandeln.
• Wenn ein Auftrag den lokalen Geschäftszeiten über die DST-Änderungen hinweg entsprechen muss, verwenden Sie einen Zeitplaner, der explizite Zeitzonen unterstützt.
• Loggen Sie den Zeitstempel jedes Laufs in UTC Siehe [Unix-Zeitstempel-Leitfaden] (/blog/unix-Zeitstempel-erläutert) warum.

Arbeitsplätze zu stärken

Richtiges Timing ist nur die Hälfte der Schlacht:

• ** Verhindern Sie Überschneidungen.** Wenn ein Job länger als sein Intervall laufen kann, verwenden Sie ein Schloss (flock bei Unix, concurrencyPolicy: Forbid bei Kubernetes).
• Make jobs idempotent. Ein Job, der zweimal ausgeführt wird, z.B. nach einem erneuten Versuch oder einer Überschneidung der DST, sollte die Kunden nicht doppelt belasten.
• Capture-Ausgabe. Klassische cron-E-Mails Ausgabe an den lokalen Benutzer, die in der Regel nirgendwohin geht. Umleiten zu Protokollen und Alarm bei Ausfällen.
• Verwenden Sie absolute Pfade. Cron läuft mit einer minimalen Umgebung und PATH; Skripte, die in Ihrer Shell funktionieren, scheitern oft unter cron.
• Monitor für die Stille. Ein Herzschlagdienst, der alarmiert, wenn eine Arbeit nicht eingestellt wird, erkennt gebrochene Zeitpläne, die sonst stillschweigend ausfallen würden.

Zusammenfassung

Die fünf Felder von Cron Minute, Stunde, Tag des Monats, Monat, Wochentag kombiniert mit Listen, Bereichen und Schritten decken fast jeden wiederkehrenden Zeitplan ab. Achten Sie auf die OR-Regel, wenn beide Tagesfelder eingestellt sind, Schritte, die an Grenzen zurückgesetzt werden, DST um 01:0003:00 Uhr und Plattformdialekte mit zusätzlichen Feldern. Überprüfen Sie jeden Ausdruck mit einem Parser, der bevorstehende Ausführungen anzeigt, bevor Sie ihn bereitstellen.