Cron: Every Midnight
0 0 * * * fires once a day at exactly midnight (00:00) — identical to the daily schedule, but the search term "every midnight" specifically emphasizes the time-of-day rather than the frequency. It's the classic slot for nightly batch jobs, log rotation, and backups.
0 0 * * *
Examples & Variations
Common Mistakes
- Scheduling every nightly job at the exact same second (0 0 * * *) — if you run several jobs this way, they all compete for resources simultaneously at midnight.
- Assuming midnight is a quiet time globally — for services with international users, midnight server time can be the middle of the business day somewhere else.
- Not accounting for the twice-a-year daylight saving transition if cron runs in local time — midnight can be skipped or duplicated on DST change days.
Best Practices
- Offset competing midnight jobs by a few minutes each (0 0, 5 0, 10 0) so they don't all spike resource usage at the exact same second.
- Run cron in UTC when the literal wall-clock hour doesn't matter to end users, sidestepping DST ambiguity entirely.
- For services with a genuinely global user base, there often isn't a universally 'quiet' hour — pick the time that's least disruptive for your specific majority timezone instead.
Frequently Asked Questions
- Is 'every midnight' the same cron expression as 'every day'?
- Yes — both resolve to 0 0 * * *. "Every midnight" just emphasizes that the daily run happens specifically at 00:00, since 'every day' technically leaves the hour unspecified until you fill it in.
- Why do so many cron jobs default to midnight?
- It's a natural, memorable boundary between calendar days and traditionally a lower-traffic hour for many businesses, making it a longstanding convention for nightly batch processing.
- How do I avoid the 'midnight thundering herd' when I have many jobs?
- Stagger their minute fields across a range (0, 5, 10, 15 minutes past midnight, etc.) instead of pinning every job to exactly 0 0 * * *.