0 0 * * *Pola
| Minuta | 0 | 0 |
|---|---|---|
| Godzina | 0 | 0 |
| Dzień miesiąca | * | dowolna |
| Miesiąc | * | dowolna |
| Dzień tygodnia | * | dowolna |
Gdzie go użyć
| crontab | 0 0 * * * /path/to/script.sh |
|---|---|
| GitHub Actions | - cron: "0 0 * * *" (on.schedule) |
| Kubernetes CronJob | schedule: "0 0 * * *" |
crontab działa w strefie czasowej serwera; GitHub Actions zawsze używa UTC.
Warto wiedzieć
0 0 * * * uruchamia się o 00:00 w strefie czasowej serwera, która na maszynach w chmurze to często UTC, a nie Twoja lokalna północ; sprawdź to poleceniem timedatectl. @daily i @midnight to skróty tego samego harmonogramu. Północ to domyślny wybór wszystkich, więc kopie zapasowe, raporty i zadania innych użytkowników serwera walczą wtedy o dysk i bazę danych; spokojniejsza pora, np. 17 0 * * *, często jest lepszym wyborem.
Cron traktuje samo % jako znak nowej linii, więc w crontabie poprzedzaj go ukośnikiem wstecznym: date -d yesterday +\%F podaje datę, którą nocne zadanie zwykle powinno przetworzyć. Jeśli serwer jest wyłączony o północy, standardowy cron nie nadrobi zaległości; anacron lub timer systemd z Persistent=true – tak. Dodaj dead man's switch, np. Healthchecks.io lub Cronitor, żeby dowiedzieć się, kiedy zadanie po cichu przestanie działać.