Cron expression for Every day at 4am

What people actually schedule with 0 4 * * *

• Post-backup verification and offsite replication — running after the 2–3am dump finishes so it operates on a complete file
• Rebuilding derived datasets (recommendations, aggregates) that depend on the night's ETL having already landed
• Sending overnight digest emails timed to land in inboxes just before the workday starts

Use 0 4 * * * 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 4 * * * /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 4 * * *"

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 4 * * *"

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 4 * * *. 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 4am schedules

• 4am assumes the 2–3am jobs already finished — verify, don't assume. If your backup at 2am occasionally runs 2.5 hours, a 0 4 * * * replication job starts copying a half-written dump. Gate on a sentinel: have the backup write /var/run/backup.done and have this job test -f it (and check its mtime is today) before proceeding.
• Digest emails fired at 4am hit the wrong time zone. 4am server-time is pre-dawn locally but could be mid-morning or mid-afternoon for users elsewhere, landing your "good morning" email at the bottom of an already-full inbox. Compute send time per-recipient time zone in the job, or schedule per-region instances.
• It's the start of the cloud-provider maintenance window. Many managed databases and load balancers default their maintenance window to roughly 3–5am, so a 4am job can hit a forced failover or a brief connection reset mid-run. Make the job idempotent and retry-safe, and check your provider's configured maintenance window so you're not scheduling straight into it.

Is 0 4 * * * the right schedule?

If this job depends on a backup, don't pick a fixed hour and hope — but if you must, 3am is too early to assume completion. For digest emails that must land at the reader's local breakfast, 9am per-time-zone beats a blind 4am UTC blast.

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

• 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 * * *
• Every day at 11am 0 11 * * *