Quick answer
The cron expression for every 3 hours is 0 */3 * * *. The */3 step in the hour field matches 0, 3, 6, 9, 12, 15, 18 and 21, and the 0 in the minute field runs the job at the top of each of those hours. That is 8 runs a day, evenly spaced because 24 divides by 3.
- Live next runs
- Any time zone
- Field-by-field breakdown
- Seven platform snippets
- Daylight saving aware
How to use this schedule
- 1Copy
0 */3 * * *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 */3 * * * mean?
The hour step */3 starts at 0 and keeps every third hour, giving eight values. Since 24 is a multiple of 3, the last gap (21:00 to midnight) is also three hours, so the rhythm never stutters. Compare 0 */5 * * *, which runs at 20:00 and then again at 00:00 after only four hours.
There are exactly three ways to place an every-3-hours schedule on the clock, one for each starting hour:
| Expression | Runs at |
|---|---|
0 */3 * * * | 00, 03, 06, 09, 12, 15, 18, 21 |
0 1-23/3 * * * | 01, 04, 07, 10, 13, 16, 19, 22 |
0 2-23/3 * * * | 02, 05, 08, 11, 14, 17, 20, 23 |
Pick the phase that suits the people or systems on the other end. The third row, for example, hits 08:00, 11:00, 14:00 and 17:00, four checkpoints that fall neatly across a working day.
When is every 3 hours a good fit?
Eight runs a day is a common rhythm for work that should stay reasonably fresh without running constantly: importing price or stock feeds, refreshing exchange rates, snapshotting a fast-changing but non-critical database, or re-checking failed webhooks.
Keep daylight saving time in mind if the schedule runs in a local zone. In America/New_York, the March night jumps from 02:00 straight to 03:00, so the gap between the 00:00 and 03:00 runs is only two real hours. In November the 01:00 hour repeats and that same gap stretches to four real hours. A job that assumes "three hours since the last run" will under- or over-collect on those days; store the timestamp of the last successful run instead.
Shorter intervals live at every 2 hours; if a few runs a day are enough, every 6 hours halves the count.
What does each field in 0 */3 * * * mean?
| Field | Value | Allowed | Meaning |
|---|---|---|---|
| Minute | 0 | 0–59 | at minute 0 (on the hour) |
| Hour | */3 | 0–23 | every 3 hours: 00:00, 03:00, 06:00 … 21: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 third hour (00:00, 03:00, 06:00 … 21:00), every day.
How do I adjust 0 */3 * * * to my own schedule?
Small edits to 0 */3 * * * cover most real-world needs:
| Expression | What it does |
|---|---|
0 1-23/3 * * * | Every 3 hours starting at 01:00 (01:00, 04:00 … 22:00) |
0 2-23/3 * * * | Every 3 hours starting at 02:00, hitting 08:00, 11:00, 14:00 and 17:00 |
30 */3 * * * | Every 3 hours at half past (00:30, 03:30 … 21:30) |
0 6-21/3 * * * | Every 3 hours from 06:00 to 21:00 only |
0 */3 * * 1-5 | Every 3 hours on weekdays |
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 2 hours · Every 4 hours · Every 6 hours · Every hour
Browse all schedules in the cron schedule library.
How do I run 0 */3 * * * in crontab, GitHub Actions, Kubernetes and the cloud?
| Platform | Write it as | Time zone |
|---|---|---|
| Linux crontab | 0 */3 * * * | Server's time zone; CRON_TZ= in cronie |
| GitHub Actions | - cron: "0 */3 * * *" | UTC by default; add timezone: (IANA name) |
| Kubernetes CronJob | schedule: "0 */3 * * *" | Set timeZone: (1.27+) |
| Cloudflare Workers | 0 */3 * * * | UTC only; numbers weekdays from 1 = Sunday, so use names |
| Vercel Cron Jobs | 0 */3 * * * | UTC only; more than once a day needs Pro (Hobby: once a day) |
| AWS EventBridge Scheduler | cron(0 */3 * * ? *) | Takes a time zone; legacy scheduled rules are UTC only |
| systemd timer | OnCalendar=*-*-* 0/3:00:00 | Add a zone after the time, e.g. Europe/London |
In a crontab (crontab -e), the full line looks like this:
0 */3 * * * /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 */3 * * *?
*/3 * * * *is every 3 minutes. For every 3 hours the step goes in the hour field and the minute needs a fixed value.- On daylight saving days in a local time zone the spacing changes: in America/New_York the gap from 00:00 to 03:00 is two real hours in March and four in November.
- Every-3-hours jobs are often long (backups, catalog imports). If one can exceed three hours, wrap it in
flock -n /tmp/job.lock your-commandto skip the next start instead of doubling up. - If the job notifies people, check which runs land at night for them: 03:00 UTC is 23:00 the previous evening in New York during daylight time.
- 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.