Every day at midnight
The log-rotation and nightly-batch default: one run a day at 00:00 — and the daylight-saving hour that can make it skip or double.
Last updated
In plain English
- Fires once per day, at 00:00
- 365 runs a year
Why it’s written this way
Minute 0, hour 0, everything else unconstrained: once a day, at the very start of the day. It's the schedule logrotate, backups and nightly ETL jobs have used for decades, mostly because midnight is quiet.
Because both time fields are single values rather than ranges or steps, this is as literal as cron gets — no field is left doing implicit work.
Edge cases to know
- →In any timezone that observes daylight saving, the midnight-to-1am hour is the one most likely to shift. Depending on the transition, a 00:00 job can run twice or not at all on changeover night.
- →Midnight is also when a lot of OTHER jobs are scheduled — disk and CPU contention right at :00 is common. If exact timing isn't sacred, nudging to 00:07 sidesteps the pile-up.
- →No built-in retry: if the box is down, rebooting, or mid-deploy at 00:00, that day's run is simply skipped, not queued for later.
Part by part
- 0 0
- Minute zero of hour zero. Read left to right, minute before hour — the reverse of how the time is spoken, which is the most common misreading of any cron line.
- * * *
- The three calendar fields left open, so the schedule repeats daily rather than landing on particular dates.
Common mistakes
@midnightA valid shorthand in Vixie cron, and not universally supported by tools that merely accept cron syntax. The explicit form travels everywhere and costs six characters.
0 0 * * *0 0 * * * cd /app && ./backup.shWithout a full path the cd may fail silently, and && then skips the backup entirely with no error anyone sees. Use absolute paths, and set -e in the script so a failed step stops it loudly.
0 0 * * * MAILTO left unset on a noisy jobCron mails output to the crontab owner by default, and on most servers that mailbox is never read. Set MAILTO to a real address or redirect explicitly — silence should be a choice, not an accident.
Questions
Why is midnight a bad time for a heavy job?
Because it is where every default schedule lands, including log rotation and the distribution's own daily maintenance. Moving a heavy job off the hour avoids competing with all of them for disk and CPU.
Which day does a midnight job belong to?
It runs at the start of the new day, so a report generated then covers the previous day's data. Off-by-one date bugs in daily reporting nearly always trace back to this being assumed rather than stated.
How do I make output go somewhere useful?
Set MAILTO at the top of the crontab for failures, and redirect stdout to a rotated log file. The combination gives you a searchable record and an alert, which cron alone provides neither of.
Does the job run if the previous day's is still going?
Yes — cron starts it regardless. For a daily job that is rarely a problem and occasionally catastrophic, as with two backups writing the same destination. flock costs nothing to add.