What is the cron expression for every day at midnight?

The cron expression for every day at midnight is "0 0 * * *". Runs once a day at 00:00 (midnight).

What should I watch out for when running a cron job every day at midnight?

Midnight is the most oversubscribed cron slot on earth. Your own box, your database, and every SaaS you call are all busy at 00:00. If the exact time doesn’t matter — and for backups it doesn’t — 0 3 * * * is the same job with no contention. On DST transition nights, 00:00 local can happen twice or never (in timezone-aware schedulers). A billing job that double-fires is a refund queue; one that skips is a revenue gap. Schedule money-touching jobs in UTC.

Cron expression for Every day at midnight

0 0 * * *

Runs once a day at 00:00 (midnight).

Next 5 runs (your local time)

These are shown in your browser’s timezone. The job itself runs in the scheduler’s timezone — often UTC — so the real run time can differ.

What people actually schedule with `0 0 * * *`

Nightly database backup before the day’s first deploy
Closing out “yesterday”: daily aggregates, usage rollups, invoice drafts
Purging expired sessions, temp files, and soft-deleted rows

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

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

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 0 * * *. 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 midnight schedules

Midnight is the most oversubscribed cron slot on earth. Your own box, your database, and every SaaS you call are all busy at 00:00. If the exact time doesn’t matter — and for backups it doesn’t — 0 3 * * * is the same job with no contention.
On DST transition nights, 00:00 local can happen twice or never (in timezone-aware schedulers). A billing job that double-fires is a refund queue; one that skips is a revenue gap. Schedule money-touching jobs in UTC.
“Yesterday” at your server’s midnight is not yesterday for your users. Decide which timezone defines the boundary before the data team builds on it.

Will you know if this job silently fails?

Cron jobs fail quietly — a server reboots, a path changes, or an error code is ignored — and nobody notices until the data is missing. A cron monitor (a dead-man’s-switch) alerts you when a scheduled job does not check in on time.

Monitor your cron jobs with UptimeRobot →

Disclosure: this is an affiliate link — we may earn a commission if you sign up, at no extra cost to you.

Is `0 0 * * *` the right schedule?

Reports a human reads at breakfast: 9am. Weekly-scale maintenance: Sunday midnight. Keep midnight for machine-only work.

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