Cron Every Hour at Half Past

30 * * * *

Every hour at 30 minutes past

Field by Field

Field	Value	Matches
Minute	30	30
Hour	*	every hour
Day of month	*	every day
Month	*	every month
Day of week	*	every day

Hourly, Off the Hour

30 * * * * fires at :30 of every hour — the same 24 runs a day as 0 * * * *, in a much quieter minute.

The Thundering Herd at :00

Every hourly job that nobody thought about runs at the top of the hour. On a shared database, a rate-limited API or a CI runner pool, that concentration is the difference between a job that takes four seconds and one that times out.

Spreading jobs across the hour costs nothing and removes an entire class of intermittent failure:

Job	Minute
Cache refresh	7
Metrics rollup	23
External sync	30
Cleanup	48

Half Past Suits Downstream Consumers

If something else runs at :00 and produces data you need, :30 gives it thirty minutes to finish. That is a much more robust arrangement than starting at :05 and hoping.

Randomising

Some schedulers accept ~ or RANDOM in the minute field to spread instances automatically. Where they do not, deriving the minute from a hash of the hostname at deploy time achieves the same thing.

Time Zones

Standard crontab evaluates in system local time. Vercel Cron, GitHub Actions, Kubernetes CronJobs and AWS EventBridge all evaluate in UTC. If converting your local time crosses midnight, the day-of-week field shifts too — weekdays at 5pm in UTC-07:00 is 0 0 * * 2-6, not 0 0 * * 1-5.

The Day-Field Trap

When both the day-of-month and day-of-week fields are restricted, cron matches either, not both. 0 0 13 * 5 runs on every 13th *and* every Friday — not Friday the 13th. Leave one of them as * unless you genuinely want the union.

Other Common Schedules

Expression	Runs
* * * * *	Every minute
*/5 * * * *	Every 5 minutes
*/15 * * * *	Every 15 minutes
0 * * * *	Every hour, on the hour
0 0 * * *	Every day at midnight
0 9 * * *	Every day at 9am
0 9 * * 1-5	Weekdays at 9am
0 9 * * 1	Every Monday at 9am

Making the Job Safe

• Assume double firing. DST transitions, restarts and retries all cause it. Make the job

idempotent rather than assuming exactly-once.

• Assume overlap. Cron starts the next run whether or not the last one finished. Take a

lock.

• Avoid :00. Every hourly job on the internet fires at the top of the hour; a random

minute spreads load on shared APIs.

• Log the start and end. A cron job that silently stops running is invisible until

someone notices the missing output.