Cron every 6 hours

0 */6 * * * runs a job four times a day, at 00:00, 06:00, 12:00 and 18:00. The 0 is the minute, and */6 in the hour field steps through the day six hours at a time, so 0 0,6,12,18 * * * is the same schedule written out.

When it fires

Checked at 09:58 UTC on October 14, the next five runs are:

Oct 14 12:00  Oct 14 18:00  Oct 15 00:00  Oct 15 06:00  Oct 15 12:00

The hours come from the clock, not from the moment the job was installed. To run at other hours, start the step elsewhere: 0 3-23/6 * * * runs at 03:00, 09:00, 15:00 and 21:00. Servers that share a database can each take a different start, so their jobs don’t all land on it at once.

Pick a quieter minute

Round hours are when the most jobs start. GitHub Actions names the start of every hour as a high-load time, when scheduled runs can be delayed. A minute other than 0 steps around the rush: 17 */6 * * * runs at 00:17, 06:17, 12:17 and 18:17.

Six hours apart, except twice a year

Cron matches clock times in its timezone. Where that zone has daylight saving time, the night the clocks change has one gap of five or seven hours instead of six. If the interval must be exact, run the schedule in UTC.

A common slip is putting the step in the first field: */6 * * * * runs every six minutes, 240 times a day. The hour is the second field.

The same schedule elsewhere

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