Runs in your browser. Your files and text never leave your device - nothing is uploaded.
At 12:00 AM
Next 8 run times
- Sat, Oct 17, 2026, 12:00 AM
- Sun, Oct 18, 2026, 12:00 AM
- Mon, Oct 19, 2026, 12:00 AM
- Tue, Oct 20, 2026, 12:00 AM
- Wed, Oct 21, 2026, 12:00 AM
- Thu, Oct 22, 2026, 12:00 AM
- Fri, Oct 23, 2026, 12:00 AM
- Sat, Oct 24, 2026, 12:00 AM
Standard 5-field cron syntax: minute, hour, day of month, month, day of week. Next run times are computed in your browser's local timezone.
What is the cron expression for every day at midnight?
0 0 * * * runs a job once a day at midnight, 00:00, the first minute of the new day, which adds up to 365 runs in 2026. The shortcuts @daily and @midnight mean the same on most Vixie-style crons. Which midnight depends on the scheduler's time zone, and GitHub Actions uses UTC by default.
0 0 * * * field by field
| Field | Allowed | Value | Selects |
|---|---|---|---|
| Minute | 0-59 | 0 | minute 0, on the hour |
| Hour | 0-23 | 0 | hour 0 only, midnight |
| Day of month | 1-31 | * | any date |
| Month | 1-12 or JAN-DEC | * | every month |
| Day of week | 0-6 or SUN-SAT (0 = Sunday; many crons also accept 7) | * | any weekday |
With both day fields left as *, every calendar date qualifies, so only the minute and hour decide when it fires.
How often 0 0 * * * runs in 2026
- Runs on each matching day: 1.
- Matching days in 2026: 365 of 365.
- Total runs in 2026: 365.
- First run of the year: Thu, 1 Jan 2026, 00:00 UTC. Last: Thu, 31 Dec 2026, 00:00 UTC.
These counts use UTC, which has no daylight saving. The run list in the generator shows the next runs in your browser's own time zone instead.
The same schedule in other schedulers
| Scheduler | Write it as | Watch out for |
|---|---|---|
| crontab (Linux, macOS) | 0 0 * * * /usr/local/bin/nightly-backup.sh | Add it with crontab -e. In /etc/crontab a user name goes between the time fields and the command. |
| Kubernetes CronJob | schedule: "0 0 * * *" | Valid; @daily and @midnight also work, and timeZone pins it to a local midnight. |
| GitHub Actions | - cron: '0 0 * * *' | Allowed; it is 00:00 UTC unless you add timezone, so check what local time that is. |
| AWS EventBridge | cron(0 0 * * ? *) | rate(1 day) repeats every 24 hours from creation rather than at midnight. |
| Quartz | 0 0 0 * * ? | Fires at 00:00:00 each day in the trigger's time zone. |
Time zones and daylight saving
Midnight is where the time zone question bites hardest. On a UTC server, 0 0 * * * is 8 p.m. the previous evening in New York during daylight saving time, 7 p.m. in winter, and 1 a.m. in London in summer. US clocks change at 2:00 a.m. and EU clocks at 01:00 UTC, so in those zones a midnight job neither skips nor repeats; check local rules if your servers sit in a zone that changes its clocks at midnight.
Common mistakes with 0 0 * * *
* 0 * * *runs every minute from 00:00 to 00:59, 60 times, not once.- Hour 24 does not exist. Hours run 0-23, so midnight is 0 and
0 24 * * *is rejected. - Off-by-one dates: a job at 00:00 on 5 March usually processes 4 March, so compute "yesterday" explicitly. In a crontab write
$(date -d yesterday +\%F), because an unescaped % ends the command line.
Frequently asked questions
0 0 * * * - At 12:00 AM. Evaluated in UTC, that comes to 365 runs in 2026, the first at Thu, 1 Jan 2026, 00:00 UTC.
On Vixie-derived crons and in Kubernetes, yes: both shortcuts expand to 0 0 * * *. GitHub Actions, AWS EventBridge and Quartz do not accept them, so there you write the fields out: 0 0 * * *, cron(0 0 * * ? *) and 0 0 0 * * ? respectively.
EventBridge: cron(0 0 * * ? *). Quartz: 0 0 0 * * ?. EventBridge adds a year field at the end and Quartz a seconds field at the start, and both need ? in one day field - here the day-of-week field, because the schedule names no weekday.
Other common schedules
Reviewed by Raja Jahangir · Last reviewed: October 7, 2026