0 0 * * *Felder
| Minute | 0 | 0 |
|---|---|---|
| Stunde | 0 | 0 |
| Tag des Monats | * | beliebig |
| Monat | * | beliebig |
| Wochentag | * | beliebig |
Wo du ihn verwendest
| crontab | 0 0 * * * /path/to/script.sh |
|---|---|
| GitHub Actions | - cron: "0 0 * * *" (on.schedule) |
| Kubernetes CronJob | schedule: "0 0 * * *" |
crontab läuft in der Zeitzone des Servers; GitHub Actions verwendet immer UTC.
Gut zu wissen
0 0 * * * läuft um 00:00 in der Zeitzone des Servers, die auf Cloud-Maschinen oft UTC ist und nicht deine lokale Mitternacht; prüfe das mit timedatectl. @daily und @midnight sind Kurzformen für denselben Zeitplan. Mitternacht ist für alle der Standard, deshalb konkurrieren dann Backups, Berichte und die Jobs anderer Mandanten um Festplatte und Datenbank; ein ruhigerer Zeitpunkt wie 17 0 * * * ist oft schonender.
Cron behandelt ein nacktes % als Zeilenumbruch, also maskiere es in der Crontab: date -d yesterday +\%F liefert das Datum, das ein nächtlicher Job normalerweise verarbeiten sollte. Ist der Server um Mitternacht aus, holt Standard-cron nichts nach; anacron oder ein systemd-Timer mit Persistent=true schon. Richte einen Dead Man’s Switch wie Healthchecks.io oder Cronitor ein, damit du erfährst, wenn der Job stillschweigend aufhört.