Cron expression for Every day at 3am

What people actually schedule with 0 3 * * *

• The default "safe" slot for nightly backups — late enough that the previous day's writes have drained, past the DST danger window
• Heavy ETL or analytics rollups that read yesterday's complete data and write into a warehouse
• Cache warming and search-index rebuilds so fresh data is ready before the morning traffic ramp

Use 0 3 * * * on your platform

It’s the same 5-field expression everywhere — what changes is where you put it and which timezone it runs in.

Linux / crontab

0 3 * * * /path/to/your-command

Runs in the server’s local timezone — check it with timedatectl. Full field reference: crontab(5) man page.

GitHub Actions

on:
  schedule:
    - cron: "0 3 * * *"

GitHub Actions always runs scheduled jobs in UTC — there is no timezone setting, and runs can be delayed under load (official docs).

Kubernetes CronJob

spec:
  schedule: "0 3 * * *"

Defaults to UTC. Set spec.timeZone (Kubernetes 1.27+) for a specific zone — see the CronJob docs.

Quartz / Spring @Scheduled

Quartz uses 6 fields (seconds first): 0 0 3 * * *. Watch out: Quartz day-of-week is 1=SUN … 7=SAT (not 0–6), and day-of-month / day-of-week use ? — double-check if your schedule touches those fields (Quartz cron reference).

Gotchas with every day at 3am schedules

• 3am is the safe side of every DST transition. Spring-forward lands on 2am and fall-back repeats the 1–2am hour, so a 0 3 * * * local-time job neither skips nor doubles — this is exactly why "3am backup" is folklore. Don't undo that safety by switching the box to a zone that shifts at 3.
• It still races the tail of the 2am crowd. If your 2am backup or OS maintenance overran, your 3am ETL starts reading a database that's mid-VACUUM and gets degraded I/O. Chain dependent jobs explicitly (a completion sentinel file, or systemd After=) instead of trusting an hour of gap to be enough.
• Long-running 3am jobs leak into business hours in other regions. A 3-hour ETL that starts at 3am server-time is finishing at 6am — fine locally, but if your users are in a +9 zone they're already at their desks. Pick the slot relative to your users' trough, not the server's, and time the job's actual duration before assuming it fits.

Is 0 3 * * * the right schedule?

If the job is light and doesn't need the full overnight settle, 2am works but risks the spring-forward skip. If you need fresh data ready earlier for an East-Asia morning, shift toward 1am and accept a slightly less-settled dataset.

Or use the interactive cron generator & explainer, read the complete cron syntax guide, or pick another common schedule:

• Every day at 4am 0 4 * * *
• Every day at 5am 0 5 * * *
• Every day at 6am 0 6 * * *
• Every day at 7am 0 7 * * *
• Every day at 8am 0 8 * * *
• Every day at 10am 0 10 * * *