Cron expression for every 30 minutes

Field breakdown

Next runs

How this schedule works

Cron evaluates the five fields of */30 * * * * — 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 30 minutes": 48 runs per day. Within every hour it fires at :00, :30. Sixty divides by 30 without a remainder, so the gap between runs stays constant as the hour rolls over.

When to use every 30 minutes

Half-hourly runs suit work that is too heavy for a five-minute loop but too time-sensitive to leave until the next hour: report refreshes, batched notification flushes, and periodic cleanup such as a vacuum or a temp-file sweep. Forty-eight runs a day give each invocation a comfortable window to finish in. It is also a sensible first cut for a job whose real cost you have not measured yet — start at thirty minutes, watch the runtime for a week, then tighten or relax the interval once you have numbers to argue from.

Common mistakes with every 30 minutes

The mistake that surfaces most often at this cadence is a neighbouring one. */45 looks like it should be the 45-minute version of this schedule, and it is not: it fires at :00 and :45 and then restarts, so the gaps alternate between 45 and 15 minutes. Only steps that divide 60 behave uniformly. The second is treating half-hourly as too cheap to think about. Forty-eight runs a day against a metered API is 17,520 a year, and a job that has quietly grown to 25 minutes is five minutes away from overlapping itself.

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

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

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

Variations

• 0,30 * * * * At 0 and 30 minutes past the hour The same two fire minutes written out. At only two values, the list is arguably clearer than the step and costs three characters.
• 15,45 * * * * At 15 and 45 minutes past the hour The same half-hourly cadence moved to a quarter past and a quarter to, which keeps the job clear of the :00 and :30 crowd on a shared host.
• */45 * * * * Every 45 minutes A cautionary counterexample. It fires at :00 and :45 only, then restarts — 45 does not divide 60, so the gaps alternate between 45 and 15 minutes.
• */30 * * * 1-5 Every 30 minutes, Monday through Friday Half-hourly on weekdays only, cutting 336 runs a week down to 240. The weekend gap is a real one, so the job must tolerate a 62-hour pause.