Cron every 3 hours

0 */3 * * * runs a job every three hours, on the hour. The 0 pins the minute, and */3 in the hour field picks 0, 3, 6, 9, 12, 15, 18 and 21: eight runs a day.

When it fires

At midnight and every third hour after it, by the clock, whenever you installed the job. Checked at 09:58 UTC, the next five runs are:

12:00  15:00  18:00  21:00  00:00

To shift the hours, give the step a start: 0 1-23/3 * * * runs at 01:00, 04:00, 07:00 and so on, so from 09:58 its next run is 10:00. 30 */3 * * * keeps the hours and runs at half past: 12:30, 15:30, 18:30.

The step starts over every day

A step counts within one field, from the field’s first value, and starts again when the field wraps. Three divides 24, so every gap here is exactly three hours. A step that doesn’t divide 24 leaves a short gap at midnight: 0 */5 * * * runs at 00:00, 05:00, 10:00, 15:00 and 20:00, then at 00:00 again only four hours later. For a true five-hour interval, use a scheduler that counts time instead of matching the clock, like EventBridge’s rate(5 hours) or a systemd timer’s OnUnitActiveSec=5h.

Leave out the leading 0 and the schedule changes completely: * */3 * * * runs every minute of those eight hours, 480 times a day.

Variations

0 */3 * * 1-5        every 3 hours, Monday to Friday
0 9-18/3 * * *       09:00, 12:00, 15:00 and 18:00
0 1-23/3 * * *       every 3 hours from 01:00: 01:00, 04:00 … 22:00

The same schedule elsewhere

• crontab: 0 */3 * * * /usr/local/bin/report.sh, in the server’s timezone unless the crontab sets CRON_TZ.
• GitHub Actions: cron: '0 */3 * * *', in UTC.
• Kubernetes CronJob: schedule: "0 */3 * * *", with spec.timeZone to pick the zone.
• AWS EventBridge: cron(0 0/3 * * ? *).
• systemd timer: OnCalendar=0/3:00, which systemd-analyze calendar normalizes to *-*-* 00/3:00:00.
• Spring @Scheduled: 0 0 */3 * * *.