Nightly at 02:30
The backup-window classic: once a day at 02:30 — plus the daylight-saving trap that makes 02:30 a risky hour to pick.
Last updated
In plain English
- Fires once per day at 02:30
- 365 runs per year — minus DST surprises
Why it’s written this way
Minute 30, hour 2, everything else unconstrained: one run per day at 02:30. Off-peak hours are the convention for backups and batch jobs because they compete least with real traffic.
Putting the minute at 30 rather than 0 also dodges the top-of-the-hour spike, when everyone else's nightly jobs fire.
Edge cases to know
- →In timezones with daylight saving, the 02:00–03:00 hour is the one that gets skipped or repeated. A 02:30 job can run zero times or twice on transition nights — schedule in UTC, or pick an hour outside the shift window.
- →Long jobs can overlap the next night's run — guard with a lockfile (flock) if a second copy would corrupt state.
- →Cron email on failure only works if MAILTO and a mailer are configured; otherwise failures are silent.
Part by part
- 30 2
- Minute 30 of hour 2 — half past two in the morning, once. The minute comes first, which is the opposite of how the time is spoken.
- * * *
- Day-of-month, month and day-of-week left open, which is what makes it every night rather than a particular one.
Common mistakes
2 30 * * *The fields reversed. Hour 30 does not exist, so a strict cron rejects the line and a lenient one may accept and never fire it — either way the job silently never runs, which is the worst failure mode a schedule has.
30 2 * * *30 2 * * 0Adding a day-of-week turns a nightly job into a weekly one. Easy to introduce while testing and easy to leave behind, because a job that runs weekly looks healthy in logs until someone counts.
0 0 * * *Midnight is the most contended minute on any shared machine, because it is the default everyone reaches for. Half past two is a deliberate choice to avoid that pile-up, and moving it back undoes the point.
Questions
Why 02:30 rather than midnight?
Two reasons: midnight is where every default schedule collides, and the small hours are when load is lowest. Half past two also sits clear of the daily log rotation that many systems run at or just after midnight.
Is this safe with daylight saving changes?
It is the riskiest hour to pick. In zones that shift at two in the morning, 02:30 may not exist on the spring transition — so the job is skipped — or may occur twice in autumn. If either matters, schedule outside that window or run the daemon in UTC.
What if the machine is off overnight?
Standard cron skips the run entirely and does not catch up. On laptops and anything not permanently on, anacron is the right tool, because it measures elapsed days rather than wall-clock moments.
How do I know it actually ran?
Cron mails output to the owning user by default, which on most servers goes nowhere anyone reads. Redirect the output to a log file you can check, or have the job report success to whatever monitoring you already have.