Every 30 minutes cron: what */30 * * * * means and the half-hour pitfalls

What */30 actually matches

In the minute field, */30 starts at 0 and adds 30, so it matches minutes 0 and 30 and nothing else. It is exactly the same as 0,30 * * * *. The remaining fields are wildcards, so there is no restriction on hour, date, month or weekday.

The parser on this page agrees: Every 30 minutes. The next run times in the panel above are computed in your browser, in your own timezone, so they are not printed in this text.

A frequent mistake is to read */30 as thirty minutes after the job last ran. Cron has no memory of previous runs: the schedule is a pattern over wall-clock minutes, and a crontab edited at 10:17 still fires next at 10:30.

Example and locking

*/30 * * * * flock -n /run/lock/reindex.lock nice -n 10 /opt/search/bin/reindex-delta is a typical half-hourly maintenance job: flock stops a slow run overlapping the next, and nice keeps it from competing with request-serving processes. Half-hourly jobs often grow slowly until one day they take 31 minutes; the lock turns that from a pile-up into a skipped run you can alert on.

Daylight saving and the server clock

Cron evaluates the expression in the cron daemon's timezone, which is normally the server's local zone (/etc/localtime) unless the crontab sets CRON_TZ. On the spring-forward night one hour disappears and its two runs with it; on the fall-back night the repeated hour can run twice more. Servers set to UTC avoid both, which is why many teams keep infrastructure clocks on UTC and convert only in reports.

systemd, Kubernetes and GitHub Actions

systemd: OnCalendar=*:0/30, or the explicit *-*-* *:00,30:00. Kubernetes accepts schedule: "*/30 * * * *" and, since version 1.27, a timeZone field such as Europe/Berlin if the half hours must follow a local clock. GitHub Actions runs it in UTC only. Related schedules: every 15 minutes doubles the frequency, every hour halves it.