What is the cron expression for every 4 hours?

The cron expression for every 4 hours is "0 */4 * * *". Runs once every 4 hours, starting at midnight.

What should I watch out for when running a cron job every 4 hours?

0 */4 * * * fires at 00,04,08,12,16,20 — and 24 divides by 4 cleanly, so the wrap-around is honest. Unlike */45, there's no uneven gap here; the only catch is people writing 0 0-23/4 thinking it differs — it's the same six slots. DST makes the 04:00 slot ambiguous. In fall-back regions the 01:00–02:00 hour repeats, and depending on cron implementation a job near that boundary can run twice; pin the schedule to UTC if these runs feed billing, dedup, or anything that breaks on a double-execution.

Cron expression for Every 4 hours

0 */4 * * *

Runs once every 4 hours, starting at 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 /4 * *`

Six-times-daily backups or snapshots that give you a tighter recovery point than nightly without the storage of hourly
Refreshing a third-party data import (CRM, ads spend, analytics) that the vendor only updates a few times a day anyway
Recomputing a recommendation or search index that's expensive enough to avoid frequent rebuilds

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 4 hours schedules

0 */4 * * * fires at 00,04,08,12,16,20 — and 24 divides by 4 cleanly, so the wrap-around is honest. Unlike */45, there's no uneven gap here; the only catch is people writing 0 0-23/4 thinking it differs — it's the same six slots.
DST makes the 04:00 slot ambiguous. In fall-back regions the 01:00–02:00 hour repeats, and depending on cron implementation a job near that boundary can run twice; pin the schedule to UTC if these runs feed billing, dedup, or anything that breaks on a double-execution.
Long-running 4-hour jobs are the worst overlap case to debug. A backup that creeps past 4 hours under load will have the next one start mid-stream, doubling I/O and possibly corrupting a half-written snapshot — guard with flock -n /var/lock/backup.lock and alert if the lock is ever contended, because that's your early warning the job is outgrowing its window.

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 /4 * *` the right schedule?

If six runs a day is overkill, every 6 hours drops you to four and still beats nightly for recovery point; if you want denser coverage, every 3 hours gives eight evenly-spaced slots.

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