Cron expression for every 6 hours

Field breakdown

Next runs

How this schedule works

Cron evaluates the five fields of 0 */6 * * * — minute, hour, day of month, month, day of week — against the clock once a minute and starts the job on any minute where all five match, which cronstrue reads as "On the hour, every 6 hours": 4 runs per day. The runs land at 00:00, 06:00, 12:00, 18:00. Twenty-four divides by 6 without a remainder, so the spacing survives midnight: the gap from the 18:00 run to the next day's 00:00 run is the same 6 hours as every other gap.

When to use every 6 hours

Four runs a day carve the day into quarters, which is the natural shape for database backups, bulk index rebuilds, and reports that are regenerated rather than incrementally updated. Six hours gives even a long job room to finish, and the fixed 00:00, 06:00, 12:00 and 18:00 slots make it easy to say which run produced a given artifact. Reach for this cadence when a daily job has grown long enough that splitting it into quarters shortens each run by more than the per-run overhead costs.

Common mistakes with every 6 hours

Six-hourly backups fail quietly in a specific way: the schedule keeps firing, the job keeps exiting zero, and the artifact it wrote is empty. Four runs a day is few enough that nobody notices until a restore is needed. Alert on the size of the output, not on the exit code. The expression-level mistake is the one every step invites — 0 6 * * * is a single daily run at 06:00, not every six hours — and if a reader might make it, the list form 0 0,6,12,18 * * * says the same thing without any ambiguity at all.

Platform snippets

The same expression, ready to paste into the four schedulers that read five-field cron. The notes below each snippet are the ones that follow from this schedule; the cron expression generator lists every caveat for every platform.

name: Scheduled workflow
on:
  schedule:
    - cron: '0 */6 * * *'
  workflow_dispatch:

jobs:
  scheduled:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run job
        run: echo "Running scheduled job"

apiVersion: batch/v1
kind: CronJob
metadata:
  name: my-cron-job
spec:
  schedule: "0 */6 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: job
              image: my-image:latest
              command: ["/bin/sh", "-c", "echo Running"]
          restartPolicy: OnFailure

{
  "$schema": "https://openapi.vercel.sh/vercel.json",
  "crons": [
    {
      "path": "/api/cron",
      "schedule": "0 */6 * * *"
    }
  ]
}

# Edit your crontab: crontab -e
0 */6 * * * /path/to/command

# With logging:
0 */6 * * * /path/to/command >> /var/log/cron.log 2>&1

Variations

• 0 */4 * * * On the hour, every 4 hours Six runs a day rather than four. The step up when a six-hour backup has grown long enough that each run is uncomfortably large.
• 0 */8 * * * On the hour, every 8 hours Three runs a day, at 00:00, 08:00 and 16:00. Eight divides 24, so the spacing stays uniform across the day boundary.
• 0 0,6,12,18 * * * At 12:00 AM, 06:00 AM, 12:00 PM and 06:00 PM The same four hours as a list. With only four values this is the clearer form, and it extends to hours a step cannot reach, such as 1,7,13,19.
• 30 */6 * * * At 30 minutes past the hour, every 6 hours The same quarter-day rhythm at half past, which keeps a heavy backup off the busiest minute on the host.