Cron Ausdruck für täglich um Mitternacht: 0 0 * * *

Der Ausdruck 0 0 * * *

Der Cron Ausdruck 0 0 * * * führt einen Job in Minute 0 von Stunde 0 (Mitternacht) jeden Tag aus. Alle fünf Felder sind: Minute (0), Stunde (0), Tag des Monats (*), Monat (*), Wochentag (*). Die Platzhalter bedeuten “jeder Wert”, also wird der Job immer dann ausgelöst, wenn Minute=0 und Stunde=0 ist, was einmal alle 24 Stunden um 00:00 passiert.

Der @daily Kurzbefehl

Die meisten Cron Implementierungen unterstützen @daily als Alias für 0 0 * * *. Es ist auch äquivalent zu @midnight, das einige Implementierungen als zusätzlichen Alias erkennen. Das Verhalten ist identisch: Ausführung zu Beginn jedes Kalendertages.

@daily          # unterstützt in Vixie cron, cronie, fcron
@midnight       # von einigen Implementierungen als äquivalent zu @daily erkannt
0 0 * * *       # funktioniert immer, portabel zwischen allen Cron Implementierungen

Wenn deine crontab von einem Tool verwaltet wird (Ansible, Chef, Puppet, Kubernetes CronJob), überprüfe, ob das Tool @daily oder nur standardmäßige 5-Felder Ausdrücke unterstützt. Kubernetes CronJob unterstützt @daily; einige ältere Systeme nicht.

Zeitzonen Fallstricke

Der Standard: Systemzeitzone

Cron liest die Zeitzone vom System (/etc/localtime oder TZ Umgebungsvariable). Auf den meisten Cloud VMs ist dies standardmäßig UTC. Auf älteren lokalen Servern kann es eine lokale Zeitzone sein. Gehe nie davon aus, welche du verwendest. Überprüfe mit timedatectl oder date, bevor du dich auf das Mitternachtsverhalten verlässt.

TZ pro crontab setzen

Vixie cron und cronie unterstützen eine TZ Direktive am Anfang der crontab:

TZ=Europe/Berlin
0 0 * * * /opt/jobs/nightly-report

Dies bewirkt, dass der Cron Daemon alle Zeiten in diesem Eintrag mit der angegebenen Zeitzone interpretiert, unabhängig von der Systemzeitzone. Nicht alle Cron Implementierungen unterstützen dies. Überprüfe es vor dem Einsatz in der Produktion.

Best Practice: Cron auf UTC ausführen

Stelle deine Server auf UTC ein und führe die Zeitzonenberechnung bei Bedarf in deiner Anwendung durch. Dadurch werden Sommerzeit Überraschungen vollständig vermieden und Log Zeitstempel sind eindeutig.

Sommerzeit und täglicher Cron

Sommerzeit Umstellungen betreffen Cron Jobs, die zu Zeiten innerhalb des Uhrenwechsel Fensters geplant sind (typischerweise 02:00 in Regionen mit Sommerzeit). Mitternacht liegt außerhalb dieses Fensters, daher wird ein 0 0 * * * Job von den meisten Sommerzeit Umstellungen nicht direkt beeinflusst.

Wenn du jedoch “Mitternacht” als “Mitternacht in einer lokalen Zeitzone” interpretierst und dein Server auf UTC läuft, musst du das Stundenfeld zweimal jährlich anpassen. Während der Mitteleuropäischen Zeit (MEZ, UTC+1) ist Mitternacht MEZ 0 1 * * * in UTC. Während der Mitteleuropäischen Sommerzeit (MESZ, UTC+2) ist Mitternacht MESZ 0 2 * * * in UTC. Einen der beiden Werte fest zu codieren bedeutet, dass der Job ein halbes Jahr lang still zur falschen Zeit ausgeführt wird.

Die saubere Lösung ist die TZ Direktive (falls unterstützt) oder UTC basierte Server mit Zeitzonenbehandlung auf Anwendungsebene.

Häufige Anwendungsfälle für täglichen Mitternachts Cron

Datenbank Backups

Backups laufen typischerweise bei geringster Last. Mitternacht vermeidet Überschneidungen mit dem Geschäftsverkehr, und das Backup ist vor Arbeitsbeginn abgeschlossen. Bei großen Datenbanken versetze den Backup Start um ein paar Minuten nach Mitternacht, um Kollisionen mit anderen Nachtjobs zu vermeiden.

Berichterstellung

Tägliche Zusammenfassungen für Dashboards, E-Mail Digests oder Analytics Pipelines werden typischerweise berechnet, nachdem die Daten des vorherigen Tages vollständig erfasst wurden. Die Ausführung um Mitternacht stellt sicher, dass der vorherige Tag abgeschlossen ist, bevor der Bericht läuft.

Datenbereinigung und Archivierung

Das Löschen abgelaufener Sitzungen, das Archivieren alter Datensätze oder das Rotieren von Logs sind Aufgaben mit niedriger Priorität, die gut um Mitternacht ausgeführt werden. Wenn die Bereinigung die Leistung beeinträchtigt (Tabellensperren, Index Rebuilds), reduziert die Durchführung außerhalb der Spitzenzeiten die Auswirkungen auf Benutzer.

ETL Pipelines

Extract Transform Load Jobs, die Daten aus externen Quellen abrufen, haben oft tägliche Update Zyklen. Ein Mitternachts Cron stimmt mit der typischen “Tagesgrenze” überein, die von den meisten Datenquellen und Data Warehouses verwendet wird.

Mehrere tägliche Jobs verteilen

Wenn du mehrere tägliche Jobs hast, kann deren Ausführung alle um 0 0 * * * zu Konflikten führen. Verteile sie:

0  0 * * *   /opt/jobs/backup-database
15 0 * * *   /opt/jobs/generate-reports
30 0 * * *   /opt/jobs/sync-external-data
45 0 * * *   /opt/jobs/cleanup-temp-files

Jeder Job beginnt 15 Minuten nach dem vorherigen, sodass der frühere Job Zeit hat, abzuschließen (oder zumindest die ressourcenintensivste Phase zu überstehen), bevor der nächste startet.

Ausführung überprüfen

Um zu sehen, wann 0 0 * * * als nächstes ausgeführt wird:

from croniter import croniter
from datetime import datetime

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

Auf einem Linux System überprüfe, ob der Job gelaufen ist, mit:

grep CRON /var/log/syslog | grep "dein-job-name"
# oder mit systemd:
journalctl -u cron --since "gestern"