Quick answer
The cron expression for every 4 hours is 0 */4 * * *. The 0 in the minute field runs the job on the hour, and */4 in the hour field keeps every fourth hour from 0 to 23, so it fires at 00:00, 04:00, 08:00, 12:00, 16:00 and 20:00: six evenly spaced runs a day. To move all six slots, start the step later, as in 0 2-22/4 * * *.
- Live next runs
- Any time zone
- Field-by-field breakdown
- Seven platform snippets
- Daylight saving aware
How to use this schedule
- 1Copy
0 */4 * * *with the Copy expression button. - 2Check Next runs in your time zone to confirm it fires when you expect, including around daylight saving changes.
- 3Pick your platform under Use it on your platform and copy the ready-made crontab line, workflow, manifest or timer.
- 4Need a different time or day? Click Customize to open it in the cron expression generator and change any field.
What does 0 */4 * * * mean?
The hour field */4 takes the hours 0 to 23 and keeps every fourth one: 0, 4, 8, 12, 16, 20. The minute field is fixed at 0, so each run lands exactly on the hour. Because 24 divides evenly by 4, the last gap of the day (20:00 to the next midnight) is also four hours, unlike */5 or */7, which leave a short gap before midnight.
There are only four distinct phases, so it is easy to pick one that suits your traffic:
| Expression | Runs at | Runs a day |
|---|---|---|
0 */4 * * * | 00, 04, 08, 12, 16, 20 | 6 |
0 1-23/4 * * * | 01, 05, 09, 13, 17, 21 | 6 |
0 2-22/4 * * * | 02, 06, 10, 14, 18, 22 | 6 |
0 3-23/4 * * * | 03, 07, 11, 15, 19, 23 | 6 |
Write the offset as a range, not 2/4: Quartz and Kubernetes accept a step after a single number, but Vixie cron and cronie (Linux crontab) reject it. To keep the job off the top of the hour as well, change the minute: 30 */4 * * * runs at 00:30, 04:30 and so on.
Every four hours suits work that should stay fresh during the day without running constantly: refreshing access tokens that expire after a few hours, rolling up metrics into a report, rebuilding a cache or search index, or syncing a product catalog from a supplier.
Which time zone do the six runs follow?
The six slots belong to the scheduler's time zone, and they only line up with your local clock when the offset is a multiple of four hours. A UTC server running 0 */4 * * * fires at 20:00, 00:00, 04:00, 08:00, 12:00 and 16:00 in New York while daylight time (UTC−4) applies, which happens to match New York's own four-hour grid. In winter (UTC−5) the same runs land at 19:00, 23:00, 03:00 and so on, an hour earlier.
If the times matter to people, pin the schedule to their zone: timezone: next to the cron entry on GitHub Actions, spec.timeZone on a Kubernetes CronJob, CRON_TZ in cronie, or EventBridge Scheduler's time zone setting. Cloudflare Workers and Vercel only run in UTC, and on Vercel six runs a day needs a Pro plan, because Hobby projects allow one run a day.
In a local zone with daylight saving time the spacing also changes twice a year. In America/New_York the spring-forward night goes from 00:00 straight to the 04:00 run after only three real hours, and the fall-back night stretches the same gap to five. If an even four-hour rhythm matters more than wall-clock times, schedule in UTC. Need more frequent runs? See every 3 hours or every 2 hours; fewer, see every 6 hours.
What does each field in 0 */4 * * * mean?
| Field | Value | Allowed | Meaning |
|---|---|---|---|
| Minute | 0 | 0–59 | at minute 0 (on the hour) |
| Hour | */4 | 0–23 | every 4 hours: 00:00, 04:00, 08:00, 12:00, 16:00 and 20:00 |
| Day of month | * | 1–31 | every day of the month |
| Month | * | 1–12, JAN–DEC | every month |
| Day of week | * | 0–7 (0 and 7 are Sunday), SUN–SAT | every day of the week |
Read together: At minute 0 of every fourth hour (00:00, 04:00, 08:00, 12:00, 16:00 and 20:00), every day.
How do I adjust 0 */4 * * * to my own schedule?
Small edits to 0 */4 * * * cover most real-world needs:
| Expression | What it does |
|---|---|
0 2-22/4 * * * | Every 4 hours starting at 02:00 (02:00, 06:00 … 22:00) |
30 */4 * * * | Every 4 hours at half past (00:30, 04:30 … 20:30) |
0 */4 * * 1-5 | Every 4 hours on weekdays only |
0 8-20/4 * * * | Every 4 hours during the day only: 08:00, 12:00, 16:00 and 20:00 |
0 0,4,8,12,16,20 * * * | The same schedule written as an explicit list |
Need something else? Click Customize at the top of the page to open this schedule in the cron expression generator and change any field.
Related schedules: Every 3 hours · Every 6 hours · Every 2 hours · Every 12 hours
Browse all schedules in the cron schedule library.
How do I run 0 */4 * * * in crontab, GitHub Actions, Kubernetes and the cloud?
| Platform | Write it as | Time zone |
|---|---|---|
| Linux crontab | 0 */4 * * * | Server's time zone; CRON_TZ= in cronie |
| GitHub Actions | - cron: "0 */4 * * *" | UTC by default; add timezone: (IANA name) |
| Kubernetes CronJob | schedule: "0 */4 * * *" | Set timeZone: (1.27+) |
| Cloudflare Workers | 0 */4 * * * | UTC only; numbers weekdays from 1 = Sunday, so use names |
| Vercel Cron Jobs | 0 */4 * * * | UTC only; more than once a day needs Pro (Hobby: once a day) |
| AWS EventBridge Scheduler | cron(0 */4 * * ? *) | Takes a time zone; legacy scheduled rules are UTC only |
| systemd timer | OnCalendar=*-*-* 0/4:00:00 | Add a zone after the time, e.g. Europe/London |
In a crontab (crontab -e), the full line looks like this:
0 */4 * * * /path/to/job.sh >> /var/log/job.log 2>&1The live panel at the top of the page builds complete, copy-ready files for each platform (workflow, CronJob manifest, wrangler.toml, vercel.json, AWS CLI and systemd units) and can shift the schedule to UTC for platforms that need it.
What can go wrong with 0 */4 * * *?
*/4 * * * *puts the step in the minute field and runs every 4 minutes. The four-hour version needs a fixed minute first:0 */4 * * *.0 2/4 * * *is Quartz and Kubernetes syntax. Linux crontab rejects a step after a single number, so write0 2-22/4 * * *instead.- In a local time zone with daylight saving time, one gap on each change night isn't four real hours: in America/New_York the 00:00 to 04:00 gap is three hours in March and five in November.
- On Vercel, six runs a day needs a Pro plan; Hobby projects only allow cron jobs that run once a day.
- In a zone with daylight saving time, a schedule with
*in the minute or hour field follows the wall clock: the spring-forward night loses an hour of runs and the fall-back night repeats one. Servers on UTC never see this.
Frequently asked questions
Last updated by the Playxoft engineering team.