Cron expression for every hour

Field breakdown

Next runs

How this schedule works

Cron evaluates the five fields of 0 * * * * — 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 "Every hour": 24 runs per day. With the hour left open and the minute pinned to 0, the job fires once in every hour of the day, at :00 — twenty-four times between one midnight and the next.

When to use every hour

Hourly is the workhorse cadence for rollups, log rotation, pruning temporary files, and pulling an upstream feed that publishes on the hour. Twenty-four runs a day keep the aggregate cost negligible while bounding staleness to sixty minutes. The thing to watch is the crowd: pinning the minute to 0 puts this job on the same tick as every other hourly job on the host and, on GitHub Actions, in the same queue as a large slice of the platform. If the exact minute does not matter, move it off :00.

Common mistakes with every hour

The single most common cron bug lives in this expression's first field. Write * * * * * instead of 0 * * * * and the job jumps from 24 runs a day to 1,440 with no error, no warning, and almost no visual difference in the crontab. Read the minute field first whenever a job is running more often than it should. The other hourly-specific mistake is leaving the minute at 0 out of habit: everything else scheduled on the machine also fires at :00, and on GitHub Actions the top of the hour is the busiest queue on the platform. Move to :07 and the contention disappears.

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

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

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

Variations

• 30 * * * * At 30 minutes past the hour Hourly at half past. Identical cadence, but it leaves the contested :00 tick to everything else on the host.
• 15,45 * * * * At 15 and 45 minutes past the hour Twice an hour, at :15 and :45. Doubles the frequency and still avoids the top of the hour entirely.
• 0 */2 * * * On the hour, every 2 hours Every other hour on the hour — twelve runs a day. The next step down when hourly turns out to be more often than the data changes.
• 0 9-17 * * 1-5 Every hour, between 09:00 AM and 05:00 PM, Monday through Friday Hourly, but only during business hours on weekdays: 45 runs a week instead of 168, with the overnight and weekend runs dropped as pure cost.