0 0 * * *Fields
| Minute | 0 | 0 |
|---|---|---|
| Hour | 0 | 0 |
| Day of month | * | any |
| Month | * | any |
| Day of week | * | any |
Where to use it
| crontab | 0 0 * * * /path/to/script.sh |
|---|---|
| GitHub Actions | - cron: "0 0 * * *" (on.schedule) |
| Kubernetes CronJob | schedule: "0 0 * * *" |
crontab runs in the server’s time zone; GitHub Actions always uses UTC.
Good to know
0 0 * * * runs at 00:00 in the server’s time zone, which on cloud machines is often UTC rather than your local midnight; check with timedatectl. @daily and @midnight are shorthands for the same schedule. Midnight is everyone’s default, so backups, reports and other tenants’ jobs compete for disk and database then; a quieter slot such as 17 0 * * * is often kinder.
Cron treats a bare % as a newline, so escape it inside the crontab: date -d yesterday +\%F gives the date a nightly job should usually process. If the server is off at midnight, standard cron doesn’t catch up; anacron or a systemd timer with Persistent=true does. Add a dead man’s switch such as Healthchecks.io or Cronitor to learn when the job silently stops.