Cron: Every 30 Minutes
*/30 * * * * fires twice an hour, at :00 and :30. It's a common choice when a job needs to run more than hourly but doesn't need quarter-hour or finer precision — think periodic backups, moderate-traffic cache refreshes, or non-urgent notification digests.
*/30 * * * *
Examples & Variations
Common Mistakes
- Writing 0,30 * * * * and */30 * * * * as if they might behave differently — they're exactly equivalent, just different notations for the same schedule.
- Using half-hourly cron for something that genuinely needs to react within minutes — this interval is too coarse for anything latency-sensitive.
- Forgetting that a half-hour window is often plenty of time for a slow job to still be running when the next invocation starts — overlap protection still matters.
Best Practices
- This interval is a solid default for periodic backups of small-to-medium datasets where minute-level freshness isn't required.
- If multiple jobs run every 30 minutes, stagger their minute offsets (0,30 vs 15,45) so they don't all compete for the same resources simultaneously.
- Document why the 30-minute interval was chosen in your crontab or job config — it saves the next engineer from guessing whether it's arbitrary or load-bearing.
Frequently Asked Questions
- What's the difference between */30 and 0,30 in the minute field?
- None — */30 is shorthand notation that expands to exactly 0,30. Both produce a job that runs at the top and bottom of every hour.
- Can I offset a 30-minute schedule to run at :15 and :45 instead?
- Yes — use an explicit list: 15,45 * * * *. Step syntax (*/30) always starts from 0, so an offset requires listing the exact minutes.
- Is 30 minutes too infrequent for uptime monitoring?
- For most services, yes — dedicated uptime monitors typically check every 1–5 minutes so an outage is caught quickly. Reserve 30-minute cron for less time-sensitive maintenance tasks.