Field breakdown
Minute 0, hour 0, and wildcards for day of month, month and day of week.
Midnight is hour 0, never 24 — the hour field only runs from 0 to 23, so
0 24 * * * is a syntax error rather than a valid way to say "end of day".
Midnight is the worst minute of the day to pick
Log rotation, backup windows, daily aggregations and the default schedule of half the software on the machine all fire at 00:00. Stacking your job there means contending for I/O with everything else, and it puts the run right at the date boundary, where "yesterday" is ambiguous for a few seconds.
Unless the job genuinely has to be the first thing that happens on the new date, a few minutes past is strictly better:
7 0 * * * /usr/local/bin/daily-rollup.shIf the job processes the previous day's data, running it at 00:07 also gives late-arriving events a moment to land.
Daylight saving time
On a server in a zone that observes daylight saving, midnight is safe — almost no zone shifts
across 00:00. The genuinely dangerous hours are 01:00 to 03:00, which is where most transitions
happen. A job at 0 2 * * * can be skipped in spring or run twice in autumn, depending on
the implementation.
Running the scheduler in UTC removes the question entirely, at the cost of the job drifting an hour relative to local business time twice a year.
Using it
# crontab, all three are equivalent
0 0 * * * /usr/local/bin/nightly.sh
@daily /usr/local/bin/nightly.sh
@midnight /usr/local/bin/nightly.sh# GitHub Actions — note this is midnight UTC, not your midnight
on:
schedule:
- cron: "0 0 * * *"Variations
| Expression | Runs |
|---|---|
| 0 0 * * * | Daily at 00:00. Same as @daily. |
| 30 2 * * * | Daily at 02:30 — a classic backup window, but DST-sensitive. |
| 0 0 * * 1-5 | Midnight on weekdays only. |
| 0 0,12 * * * | Twice a day, at midnight and noon. |
| 0 0 1 * * | Midnight on the 1st of each month. |
| 0 4 * * * | Daily at 04:00 — quiet, and clear of every DST transition. |