What is the cron expression for every 3 hours?

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

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

0 */3 * * * anchors to midnight, not to 'now'. It fires at 00,03,06,09,12,15,18,21 — so if you deploy at 14:50 expecting 3-hour spacing from launch, your first run is at 15:00 (10 min later), then 18:00. The cadence is clock-aligned, not deploy-aligned. 24 isn't divisible by leaving 21:00 → 00:00 as a clean 3 hours — but DST shifts it. On the spring-forward day, the 02:00–03:00 hour vanishes, so a slot that should fire near 03:00 may run immediately or skip depending on your cron's DST handling; for anything financial or audit-sensitive, run cron in UTC to sidestep the missing/duplicated hour.

Cron expression for Every 3 hours

0 */3 * * *

Runs once every 3 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 /3 * *`

Eight-times-a-day catalog or inventory sync with a supplier feed that refreshes a few times during business hours
Rolling up application metrics into a summary table on a cadence that's cheap to store and query
Re-fetching OAuth tokens or rotating short-lived credentials that expire on a multi-hour window

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

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 */3 * * *"

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 */3 * * *. 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 3 hours schedules

0 */3 * * * anchors to midnight, not to 'now'. It fires at 00,03,06,09,12,15,18,21 — so if you deploy at 14:50 expecting 3-hour spacing from launch, your first run is at 15:00 (10 min later), then 18:00. The cadence is clock-aligned, not deploy-aligned.
24 isn't divisible by leaving 21:00 → 00:00 as a clean 3 hours — but DST shifts it. On the spring-forward day, the 02:00–03:00 hour vanishes, so a slot that should fire near 03:00 may run immediately or skip depending on your cron's DST handling; for anything financial or audit-sensitive, run cron in UTC to sidestep the missing/duplicated hour.
The midnight slot collides with nightly jobs. The 00:00 run lands in the same window as backups, logrotate, and certbot; if your 3-hour job is I/O-heavy, stagger it to 5 */3 * * * or similar so it isn't fighting the nightly cron crowd for disk.

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

If eight runs a day is more than the data justifies, every 6 hours halves it to four clean slots; if you need tighter freshness during the day, every 2 hours steps up to twelve evenly-spaced runs.

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