Toolman 100% local

Cron expression: every 30 minutes

*/30 * * * *

Runs 2 times an hour, at minute 0, 30 past every hour.

What each field means

FieldValueMeaning
minute*/30every 30 minutes
hour*every hour
day of month*every day of month
month*every month
day of week*every day of week

Next runs

Starting from 1 January 2026, 00:00 UTC:

Things to watch

Because 30 divides evenly into 60, the schedule is regular across every hour boundary.

Worth noting where in the hour it lands. This fires at :00, :30, every one of them a quarter-hour mark — the busiest minutes on any machine, because that is where everything else is scheduled too. If the job competes for a database or an API quota, the contention is easier to remove than to tune around: 23-59/30 * * * * runs on exactly the same 30-minute cadence, at :23, :53, and shares those minutes with almost nothing.

This fires 48 times a day, once every 30 minutes. That number is worth looking at before anything else: whatever the job costs — a database query, an API call, a container start — multiply it by 48 and check the result is one you are willing to pay every day.

30 minutes is a comfortable polling cadence: frequent enough that nothing waits long, and slow enough that overlap only matters if the job is genuinely slow. It is the interval most status checks and queue drains end up at.

The same schedule elsewhere

# crontab
*/30 * * * * /usr/local/bin/my-job >> /var/log/my-job.log 2>&1

# GitHub Actions (.github/workflows/job.yml) — always UTC
on:
  schedule:
    - cron: '*/30 * * * *'

# Kubernetes CronJob
spec:
  schedule: "*/30 * * * *"

# AWS EventBridge — six fields, and ? in one of the day fields
cron(*/30 * * * ? *)

Frequently asked questions

What is the cron expression to run a job every 30 minutes?

*/30 * * * * — Runs 2 times an hour, at minute 0, 30 past every hour.

Which time zone does cron use?

The server's local time zone, unless the scheduler says otherwise. GitHub Actions always uses UTC. Kubernetes CronJobs use UTC unless you set spec.timeZone. Running servers in UTC and converting only for display avoids an entire class of daylight-saving bugs.

What happens if the previous run is still going?

Standard cron starts a new one regardless, so long-running jobs can pile up. Wrap the command in flock -n /var/lock/my-job.lock, or set concurrencyPolicy: Forbid on a Kubernetes CronJob.

Why did my cron job not run at all?

The three usual causes: the script is not executable, the command relies on a PATH or environment variable that cron does not set, or output went nowhere because no mail transport is configured. Redirect stdout and stderr to a log file and the reason usually becomes obvious.

Other schedules

Build a custom cron expression →