Cron Every 3 Hours

0 */3 * * *

At 8 times a day

Field by Field

Field	Value	Matches
Minute	0	0
Hour	*/3	0, 3, 6, 9, 12, 15, 18, 21
Day of month	*	every day
Month	*	every month
Day of week	*	every day

Eight Runs a Day

Matching hours are 0, 3, 6, 9, 12, 15, 18 and 21 — evenly spaced, anchored to midnight. Three divides 24 exactly, so unlike a five- or seven-hour step there is no awkward wrap at the end of the day.

Steps Must Divide Cleanly to Be Even

*/5 in the hour field gives 0, 5, 10, 15 and 20 — then jumps four hours to the next midnight. Any step that does not divide 24 produces an uneven final gap. The clean divisors are 1, 2, 3, 4, 6, 8 and 12.

Interleaving

If a heavier job already runs every six hours at 0, 6, 12 and 18, this schedule adds runs at 3, 9, 15 and 21 — filling the gaps without ever colliding. Offsetting the minute as well (10 */3 * * *) guarantees separation even when both fire in the same hour.

Retry Spacing

At three-hour intervals, a failed run leaves a three-hour hole. Schedule a retry ten minutes later inside the job rather than adding a second cron entry — a retry that lives in the job knows whether the first attempt succeeded.

Time Zones

Standard crontab evaluates in system local time. Vercel Cron, GitHub Actions, Kubernetes CronJobs and AWS EventBridge all evaluate in UTC. If converting your local time crosses midnight, the day-of-week field shifts too — weekdays at 5pm in UTC-07:00 is 0 0 * * 2-6, not 0 0 * * 1-5.

The Day-Field Trap

When both the day-of-month and day-of-week fields are restricted, cron matches either, not both. 0 0 13 * 5 runs on every 13th *and* every Friday — not Friday the 13th. Leave one of them as * unless you genuinely want the union.

Other Common Schedules

Expression	Runs
* * * * *	Every minute
*/5 * * * *	Every 5 minutes
*/15 * * * *	Every 15 minutes
0 * * * *	Every hour, on the hour
0 0 * * *	Every day at midnight
0 9 * * *	Every day at 9am
0 9 * * 1-5	Weekdays at 9am
0 9 * * 1	Every Monday at 9am

Making the Job Safe

• Assume double firing. DST transitions, restarts and retries all cause it. Make the job

idempotent rather than assuming exactly-once.

• Assume overlap. Cron starts the next run whether or not the last one finished. Take a

lock.

• Avoid :00. Every hourly job on the internet fires at the top of the hour; a random

minute spreads load on shared APIs.

• Log the start and end. A cron job that silently stops running is invisible until

someone notices the missing output.