Cron expression for every 4 hours

Field breakdown

Next runs

How this schedule works

Cron evaluates the five fields of 0 */4 * * * — 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 4 hours": 6 runs per day. The runs land at 00:00, 04:00, 08:00, 12:00, 16:00, 20:00. Twenty-four divides by 4 without a remainder, so the spacing survives midnight: the gap from the 20:00 run to the next day's 00:00 run is the same 4 hours as every other gap.

When to use every 4 hours

Six runs a day suit batch processing that is comfortably slower than the data arrives, long-lived cache refreshes, and housekeeping such as session cleanup or credential rotation. Four hours is roughly the point where a job stops being a poll and starts being a batch: each run can take tens of minutes without crowding the next one out. Choose it when the work is chunky, the upstream is slow-moving, and a four-hour-old view of the world is still a useful one for whoever ends up reading it.

Common mistakes with every 4 hours

Confusing 0 */4 * * * with 0 4 * * * is the usual slip: the first is six runs a day, the second is one run at 04:00. Both parse, neither errors, and the difference only shows up in a dashboard nobody is watching. Beyond that, the mistake specific to four-hourly batches is scope creep inside the job. A run that started at two minutes grows quarter by quarter until it takes an hour — still comfortably inside the interval, so nothing complains, but the output is now an hour staler than everyone assumes. Track the runtime trend, not just the exit code.

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 */4 * * *'
  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 */4 * * *"
  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 */4 * * *"
    }
  ]
}

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

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

Variations

• 0 */6 * * * On the hour, every 6 hours Four runs a day. Six also divides 24, so the quarter-day spacing holds across midnight exactly as the four-hour one does.
• 0 */12 * * * On the hour, every 12 hours Down to twice a day, locked to 00:00 and 12:00. A much wider window per run, and a much longer wait when one fails.
• 0 0,4,8,12,16,20 * * * At 12:00 AM, 04:00 AM, 08:00 AM, 12:00 PM, 04:00 PM and 08:00 PM The same six hours as a list. At six values it is still readable, and it makes the fire times obvious without any arithmetic.
• 15 */4 * * * At 15 minutes past the hour, every 4 hours The same six hours, offset to a quarter past. The minute field moves freely without disturbing the hour step at all.