Runs in your browser. Your files and text never leave your device - nothing is uploaded.
Every hour
Next 8 run times
- Sat, Oct 17, 2026, 12:00 AM
- Sat, Oct 17, 2026, 01:00 AM
- Sat, Oct 17, 2026, 02:00 AM
- Sat, Oct 17, 2026, 03:00 AM
- Sat, Oct 17, 2026, 04:00 AM
- Sat, Oct 17, 2026, 05:00 AM
- Sat, Oct 17, 2026, 06:00 AM
- Sat, Oct 17, 2026, 07: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 hour?
0 * * * * runs a job once an hour, at minute 0: 00:00, 01:00, 02:00 and so on, 24 times a day and 8,760 times in 2026. Most cron daemons also accept @hourly for exactly this schedule. The leading 0 matters, since * * * * * would run every minute instead.
0 * * * * field by field
| Field | Allowed | Value | Selects |
|---|---|---|---|
| Minute | 0-59 | 0 | minute 0, on the hour |
| Hour | 0-23 | * | every hour of the day (0-23) |
| 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 * * * * runs in 2026
- Runs on each matching day: 24.
- Matching days in 2026: 365 of 365.
- Total runs in 2026: 8,760.
- First run of the year: Thu, 1 Jan 2026, 00:00 UTC. Last: Thu, 31 Dec 2026, 23: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 * * * * /usr/local/bin/rotate-logs.sh | Add it with crontab -e. In /etc/crontab a user name goes between the time fields and the command. |
| Kubernetes CronJob | schedule: "0 * * * *" | Valid, and Kubernetes also accepts @hourly. |
| GitHub Actions | - cron: '0 * * * *' | Allowed, but the start of the hour is when Actions is busiest; a later minute such as 17 * * * * is less likely to be delayed. |
| AWS EventBridge | cron(0 * * * ? *) | rate(1 hour) counts from when the schedule is created rather than from the top of the hour. |
| Quartz | 0 0 * * * ? | Fires at second 0 of minute 0, every hour. |
Time zones and daylight saving
An hourly job is where daylight saving shows most clearly on a local-time server: the spring-forward day has 23 hours, so 23 runs, and the autumn day has 25. If downstream reports expect 24 rows per day, run the job in UTC. Zones with half-hour offsets, such as India at UTC+5:30, see a UTC-scheduled hourly job land at half past each local hour.
Common mistakes with 0 * * * *
* * * * *or* */1 * * *instead of0 * * * *: both run every minute, because the minute field is still a wildcard.- Putting every hourly job on minute 0. That is when many systems fire at once; a fixed odd minute such as
17 * * * *spreads the load. - Assuming
@hourlyworks everywhere. Vixie-style crons and Kubernetes accept it, but GitHub Actions, AWS EventBridge and Quartz need the explicit fields.
Frequently asked questions
0 * * * * - Every hour. Evaluated in UTC, that comes to 8,760 runs in 2026, the first at Thu, 1 Jan 2026, 00:00 UTC.
None on Vixie-derived crons such as cronie, or in Kubernetes: @hourly is defined as 0 * * * *. The shortcut is not part of POSIX cron, though, so tools that accept only the five fields, including GitHub Actions, need the explicit form.
EventBridge: cron(0 * * * ? *). Quartz: 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