Cron Ausdruck für jede Stunde: 0 * * * *

Der Ausdruck 0 * * * *

Der Cron Ausdruck 0 * * * * führt einen Job in Minute 0 jeder Stunde aus. Die fünf Felder sind Minute, Stunde, Tag des Monats, Monat, Wochentag. Das Setzen der Minute auf 0 und die Verwendung von * für alles andere bedeutet, dass der Job um 00:00, 01:00, 02:00 und so weiter ausgelöst wird, genau 24 Mal pro Tag.

Warum das Minutenfeld wichtig ist

Die häufigste Ursache für außer Kontrolle geratene Cron Jobs ist die Verwechslung von * * * * * mit 0 * * * *.

* * * * *    # läuft jede Minute, 1440 Mal/Tag
0 * * * *    # läuft jede Stunde, 24 Mal/Tag

Wenn du einen Job stündlich ausführen möchtest und * * * * * schreibst, wirst du das Problem nicht bemerken, bis du deine Logs überprüfst und siehst, dass er den ganzen Tag gelaufen ist. Überprüfe bei stündlichen Zeitplänen immer das Minutenfeld.

Die @hourly Abkürzung

Die meisten Cron Implementierungen unterstützen eine Reihe von @ Abkürzungen:

@hourly wird in Vixie cron (dem Standard auf den meisten Linux Distributionen), cronie und vielen verwalteten Cron Diensten unterstützt. Es ist nicht Teil des POSIX Standards. Wenn du also eine portable crontab schreibst oder eine minimalistischere Cron Implementierung verwendest, bleibe bei 0 * * * *.

Stündliche Jobs verteilen

Wenn mehrere Dienste alle einen stündlichen Job ausführen, erzeugt deren Planung alle um 0 * * * * eine Lastspitze zu jeder vollen Stunde. Alles feuert gleichzeitig, Datenbanken werden auf einmal getroffen, und nachgelagerte Dienste sehen alle 60 Minuten einen Nutzungsspitze.

Die Lösung besteht darin, jeden Job um ein paar Minuten zu versetzen:

0  * * * *   /opt/jobs/report-generator
7  * * * *   /opt/jobs/cache-warmer
14 * * * *   /opt/jobs/data-sync
21 * * * *   /opt/jobs/cleanup

Diese vier Jobs laufen jetzt jeweils zu ihrer eigenen Minute nach der vollen Stunde und verteilen die Last gleichmäßig. Die Offsets sind willkürlich. Der Punkt ist, dass sie sich nicht alle überschneiden.

Für größere Gruppen funktionieren zufällige Offsets (bei der Bereitstellung gewählt und in die crontab eingebacken) besser als handverlesene, da Entwickler dazu neigen, dieselben “offensichtlichen” Offsets zu wählen.

Wann stündlich die richtige Wahl ist

Berichterstellung

Stündliche Zusammenfassungen sind eine natürliche Grenze für Dashboards, die “letzte Stunde” Metriken anzeigen. Die Erstellung des Berichts zur vollen Stunde (oder kurz danach mit einem kleinen Offset) stellt sicher, dass die Daten ein sauberes Fenster abdecken.

Externer API Sync

Wenn du Daten aus einem externen Dienst abrufst und sich die Daten höchstens einmal pro Stunde ändern, verschwendet häufigeres Polling das Kontingent. Ein stündlicher Cron, der auf den Aktualisierungsrhythmus der Daten abgestimmt ist, ist korrekt.

Token oder Sitzungs Refresh

Kurzlebige Anmeldedaten, die alle paar Stunden ablaufen, können stündlich als Sicherheitsmarge erneuert werden. Dies ist einfacher, als zu versuchen, den Ablauf zu erkennen und bei Bedarf zu erneuern.

Bereinigungsaufgaben

Das Löschen temporärer Dateien, das Bereinigen abgelaufener Cache Einträge oder das Archivieren alter Datensätze wird oft stündlich durchgeführt. Der genaue Zeitpunkt spielt normalerweise keine Rolle, daher ist dies auch ein guter Kandidat für einen versetzten Zeitplan.

Wann stündlich zu selten ist

Wenn die akzeptable Latenz für die Erkennung eines Problems oder die Synchronisierung von Daten weniger als eine Stunde beträgt, ist Cron immer noch eine Option, aber du benötigst ein kürzeres Intervall wie */5 * * * * oder */15 * * * *. Wenn du Subminuten Granularität oder garantierte Ausführungszeiten benötigst, erwäge einen dedizierten Scheduler, eine Message Queue mit Verzögerung oder einen langlebigen Prozess mit einer internen Schleife.

Nächste Ausführungszeiten bestätigen

Um die nächsten Ausführungszeiten für 0 * * * * * zu überprüfen, verwende das Cron Builder Tool auf dieser Seite oder prüfe mit Python:

from croniter import croniter
from datetime import datetime

cron = croniter("0 * * * *", datetime.now())
for _ in range(5):
    print(cron.get_next(datetime))

Du kannst auch bestätigen, dass der Zeitplan auf einem Linux System aktiv ist, mit crontab -l, und die Ausführung mit grep CRON /var/log/syslog oder journalctl -u cron überprüfen.