Cron daily at 2am
0 2 * * * runs once a day at 02:00 server time. It is the classic slot for backups and cleanup — and, in any country that observes daylight saving, the single worst hour to choose: 02:00 is exactly where clocks jump. Pick 01:00 or 03:00 and the problem disappears.
At 02:00.
Next runs — UTC
- Mon, 31 Aug 2026, 02:00
- Tue, 01 Sept 2026, 02:00
- Wed, 02 Sept 2026, 02:00
- Thu, 03 Sept 2026, 02:00
- Fri, 04 Sept 2026, 02:00
Five fields. Runs in the server's local timezone.
Cron uses the server’s timezone, which is often not yours. Check before you trust a time.
Fields
- minute0–59
- hour0–23
- dom1–31
- month1–12
- dow0–7
The expression
0 2 * * *
Edit it above to see the next run times update, or switch dialect if your scheduler uses a different format.
Frequently asked questions
- What happens to a 2am job when the clocks change?
- In a daylight-saving timezone, the job runs twice on the day clocks go back — 02:00 happens twice — and not at all on the day they jump forward, because 02:00 never occurs. The preview above flags both. Scheduling at 01:00 or 03:00 avoids it, and running the server in UTC avoids it entirely.
- Which timezone does cron use?
- The server's local timezone, unless the system sets CRON_TZ or the platform overrides it. GitHub Actions always uses UTC. This is worth checking rather than assuming — it is the other half of why 2am jobs surprise people.
- How do I run at 2:30am instead?
- Put the minutes first: 30 2 * * *. The minute field always comes before the hour, which is the reverse of how you say it out loud.