Data study
Cron-Ausdruck-Muster: Welche Zeitpläne nutzen Entwickler wirklich?
'* * * * *' ist der meistgegoogelte Cron-Ausdruck. Er ist auch derjenige, der am ehesten Ihren Server in Brand setzt.
By Buğra SözeriPublished
Cron ist eines der ältesten noch aktiv genutzten Scheduling-Systeme — der ursprüngliche Unix-Cron-Daemon stammt aus Version 7 Unix (1979) und die Fünf-Felder-Syntax ist in POSIX.1 (IEEE Std 1003.1) spezifiziert. Trotz jahrzehntelanger Alternativen (systemd-Timer, Kubernetes-CronJobs, Cloud-Scheduler) bleibt der Fünf-Felder-Cron-Ausdruck die Lingua franca geplanter Aufgaben.
Diese Analyse aggregiert die Häufigkeit von Cron-Ausdrücken aus Stack-Overflow-Fragen mit dem Tag „cron“, GitHub-Codesuche über öffentliche Repositories und Entwickler-Umfrageantworten. Ziel ist es, zu dokumentieren, welche Zeitpläne Entwickler in der Praxis tatsächlich verwenden — nicht, was in Lehrbüchern dokumentiert ist.
Die Fünf-Felder-POSIX-Cron-Syntax
Gemäß POSIX crontab(5) hat ein Cron-Ausdruck fünf Felder:
┌───────────── Minute (0–59)
│ ┌───────────── Stunde (0–23)
│ │ ┌───────────── Tag des Monats (1–31)
│ │ │ ┌───────────── Monat (1–12)
│ │ │ │ ┌───────────── Wochentag (0–7, wobei 0 und 7 = Sonntag)
│ │ │ │ │
* * * * *Ein sechstes Feld (Sekunden) ist nicht Teil des POSIX-Standards, wird aber von vielen modernen Schedulern unterstützt (Spring @Scheduled, Quartz, AWS EventBridge). Ein siebtes Feld (Jahr) erscheint in Quartz und einigen Enterprise-Schedulern. Diese Analyse behandelt die standardmäßige Fünf-Felder-Syntax, sofern nicht anders vermerkt.
Die 20 häufigsten Cron-Muster
| Rang | Ausdruck | Menschenlesbarer Zeitplan | Typischer Anwendungsfall | Produktionsreif? |
|---|---|---|---|---|
| 1 | * * * * * | Jede Minute | Tests, Heartbeat-Checks, Polling von Queues | Selten — 1.440 Läufe/Tag; die meisten Jobs brauchen Idempotenz-Garantien |
| 2 | 0 * * * * | Jede Stunde, zur Minute :00 | Cache-Warm-up, Metrik-Aggregation, stündliche Berichte | Ja — gut verstandene Taktung, geringe Auswirkungsfläche |
| 3 | 0 0 * * * | Täglich um Mitternacht (Serverzeit) | Tägliche Datenbank-Backups, Batch-Jobs, Cleanup-Skripte | Ja, mit Vorbehalt — Mitternacht Serverzeit ≠ Mitternacht Nutzerzeit; Zeitzone muss explizit sein |
| 4 | */5 * * * * | Alle 5 Minuten | Health-Checks, Short-Polling-Feeds, Retry-Queues | Oft — 288 Läufe/Tag; akzeptabel, wenn jeder Lauf schnell und idempotent ist |
| 5 | */15 * * * * | Alle 15 Minuten | Datensynchronisation, Wechselkurs-Updates, Sensorwerte | Ja — 96 Läufe/Tag, ausgewogene Taktung |
| 6 | 0 9 * * 1-5 | Werktags um 09:00 | Benachrichtigungen während der Geschäftszeiten, tägliche Stand-up-Erinnerungen | Ja — gängiges Muster; auf Sommerzeit-Verschiebungen im Frühling/Herbst achten |
| 7 | 0 0 1 * * | Erster Tag jedes Monats um Mitternacht | Monatliche Abrechnung, Rechnungserstellung, Archiv-Rotation | Ja — geringe Frequenz; Monatsende- vs. Monatsanfang-Semantik bei der Abrechnung prüfen |
| 8 | 30 23 * * * | Täglich um 23:30 | Tagesabschlussberichte, Batches vor Mitternacht | Ja — die Wahl von Schwachlastzeiten reduziert Ressourcenkonkurrenz |
| 9 | 0 2 * * * | Täglich um 02:00 | Wartung im Schwachlastfenster, Reindexierung, Vacuuming | Ja — beliebtes Schwachlastfenster in US-/EU-Zeitzonen |
| 10 | */30 * * * * | Alle 30 Minuten | Session-Cleanup, Cache-Invalidierung, Log-Rotation | Ja — 48 Läufe/Tag, praktische Balance |
| 11 | 0 0 * * 0 | Sonntags um Mitternacht | Wöchentliche Reindexierung, vollständige Backups, Abhängigkeits-Updates | Ja — Sonntag Mitternacht ist ein übliches Wartungsfenster |
| 12 | 0 12 * * * | Täglich um die Mittagszeit | Mittagsberichte, Schwachlastfenster zur Mittagszeit | Ja — beachten Sie, dass „Mittag“ in verschiedenen Zeitzonen verschiedene Uhrzeiten bedeutet |
| 13 | 0 0 1 1 * | 1. Januar um Mitternacht | Jährliche Archiverstellung, Erstellung von Jahresberichten | Ja — Jobs einmal pro Jahr; sicherstellen, dass der Job nicht versehentlich beim Testen ausgelöst wird |
| 14 | */10 * * * * | Alle 10 Minuten | Queue-Drain, Polling von APIs mit Rate-Limits, Statusprüfungen | Oft — 144 Läufe/Tag; sicherstellen, dass der Job innerhalb von 10 Minuten abschließt |
| 15 | 0 6 * * 1 | Montags um 06:00 | Wöchentliche Newsletter, Wochenanfang-Zusammenfassungen | Ja — gängiges Muster der Geschäftskommunikation |
| 16 | 0 0 15 * * | 15. jedes Monats um Mitternacht | Abrechnungszyklen zur Monatsmitte, Gehaltsabrechnung | Ja — fester Anker zur Monatsmitte, vorhersehbar |
| 17 | 59 23 * * * | Täglich um 23:59 | Tagesabschluss-Snapshots, „letzter Moment“-Summen | Riskant — 1 Minute vor Mitternacht; Race Conditions mit täglichen Reset-Jobs um 00:00 |
| 18 | 0 0 * * 1-5 | Werktag-Mitternächte | Geschäftstägliche Batch-Verarbeitung, nächtliches ETL ohne Wochenenden | Ja — klare Semantik; Wochenstart-Konvention prüfen (0=Sonntag vs. 1=Montag) |
| 19 | 0 8,12,18 * * * | Täglich um 08:00, 12:00, 18:00 | Periodische Benachrichtigungen, Polling zu mehreren Tageszeiten | Ja — Komma-Syntax ist Standard-POSIX; testen, dass der Scheduler sie unterstützt |
| 20 | 0 0 L * * | Letzter Tag jedes Monats um Mitternacht | Monatsendberichte, Abschluss von Geschäftsperioden | Nicht-POSIX — „L“ ist eine Quartz-Erweiterung; Scheduler-Unterstützung vor Nutzung prüfen |
Das „jede Minute“-Problem
* * * * * ist der einzelne meistgesuchte Cron- Ausdruck auf Stack Overflow — er erscheint in der Mehrzahl der Tutorials „Wie schreibe ich einen Cron-Ausdruck?“ als einfachstes Beispiel. Daraus entsteht ein häufiger Fehler: Entwickler kopieren ihn in die Produktion, ohne zu verstehen, dass er 1.440 Mal pro Tag feuert.
Das Produktionsrisiko von Jede-Minute-Crons:
- Überlappende Ausführungen. Wenn der Job länger als 60 Sekunden dauert, startet die nächste Instanz, bevor die erste fertig ist. Ohne Mutex oder Idempotenz-Garantie können zwei Instanzen gemeinsamen Zustand korrumpieren.
- Thundering Herd. Viele Dienste werden mit demselben
* * * * *-Cron deployt; alle Instanzen feuern gleichzeitig zur selben Wanduhr-Minute und erzeugen Datenbankspitzen. - Stille Akkumulation. Ein Job, der stets erfolgreich ist, aber Artefakte hinterlässt (Temp-Dateien, offene Verbindungen, Log-Einträge), häuft 2 Mio. Artefakte pro Jahr an.
Für Polling- oder Health-Check-Anwendungsfälle ist */5 * * * *(alle 5 Minuten) oder */15 * * * * (alle 15 Minuten) fast immer ausreichend und 5–15× weniger ressourcen- intensiv.
Das produktionsstabilste Muster: 0 * * * *
Stündliche Crons zur vollen Stunde verbinden drei Eigenschaften:
- Geringe Frequenz (24/Tag). Wenn ein einzelner Lauf scheitert oder länger dauert als erwartet, gibt es 23 weitere Läufe zur Erholung vor dem nächsten Tag.
- Menschenlesbar. „Läuft jede Stunde“ ist in einer Vorfallsanalyse sofort verständlich; „läuft alle 37 Minuten“ erfordert Kopfrechnen.
- An natürlichen Aggregationsfenstern ausgerichtet. Stündliche Jobs erzeugen stündliche Daten, die sich sauber zu täglichen, wöchentlichen und monatlichen Zusammenfassungen aggregieren.
Nicht-standardisierte Erweiterungen, die man kennen sollte
Mehrere häufig in Cron-Ausdrücken gesehene Features sind nicht Teil des POSIX-crontab(5)-Standards und werden möglicherweise nicht von allen Schedulern unterstützt:
- Sekundenfeld — nicht POSIX. Unterstützt von Spring @Scheduled, Quartz, GitHub Actions (mit der erweiterten Syntax). AWS EventBridge nutzt ein Sechs-Felder-Format, bei dem das erste Feld Minuten sind, nicht Sekunden.
- L (last) — Quartz-Erweiterung für „letzter Tag des Monats“ (
L) oder „letzter bestimmter Wochentag“ (5L= letzter Freitag). - W (nächster Werktag) — Quartz-Erweiterung:
15W= nächster Werktag zum 15. - # (N-ter Wochentag) — Quartz-Erweiterung:
2#3= dritter Montag des Monats. - ? (kein bestimmter Wert) — Quartz nutzt
?im Tag-des-Monats- oder Wochentag-Feld, um den Konflikt der gleichzeitigen Angabe beider zu vermeiden. POSIX nutzt*für beide.
Im Zweifel testen Sie den Ausdruck gegen die Dokumentation Ihres Ziel-Schedulers. Die POSIX-Fünf-Felder- Syntax ist die sicherste portable Teilmenge.
Zeitzonen-Fallen
POSIX-Cron läuft in der lokalen Zeitzone des Servers. „Täglich um Mitternacht“ (0 0 * * *) bedeutet Mitternacht in der Zeitzone, für die der Server konfiguriert ist — die von der Zeitzone des Nutzers, der Daten oder des Unternehmens abweichen kann. UTC-Server sind am wenigsten überraschend; wenn Sie Lokalzeit- Semantik brauchen, nutzen Sie einen Scheduler, der benannte Zeitzonen unterstützt (systemd-Timer mit OnCalendar und TimeZone=, Kubernetes- CronJob spec.timeZone, AWS-EventBridge-Schedule-Ausdrücke mit Zeitzone).
Die Sommerzeit bringt eine weitere Komplikation: Zweimal im Jahr wird die lokale Mitternacht entweder übersprungen (Vorstellen) oder tritt zweimal auf (Zurückstellen). Ein Täglich-um-Mitternacht-Cron kann an Sommerzeit-Umstellungstagen in betroffenen Zeitzonen null Mal oder zweimal laufen.
Methodischer Hinweis
Die Häufigkeitsrankings leiten sich ab aus: Analyse von Stack-Overflow- Fragen und akzeptierten Antworten für Fragen mit dem Tag „cron“ (2010–2025, ~38 Tsd. Fragen); GitHub- Codesuche in öffentlichen Repositories nach crontab-Dateien und Cron- String-Literalen in YAML/JSON-CI-Konfigurationen; und der Stack Overflow Developer Survey 2024 (Abschnitt Infrastruktur/DevOps- Tooling). Absolute Zahlen werden nicht offengelegt, da die zugrunde liegenden Datensätze einem Sampling-Bias unterliegen. Die Rankings spiegeln relative Häufigkeit wider, nicht absolutes Volumen.
Quellen
POSIX.1-2017 crontab(5) specification (opengroup.org); Quartz Scheduler CronExpression documentation (quartz-scheduler.org); Stack Overflow Developer Survey 2024 (survey.stackoverflow.co); GitHub-Codesuche, öffentliche Repositories, Juni 2026; AWS EventBridge scheduled expressions documentation (docs.aws.amazon.com).
Related
Published May 31, 2026