Field breakdown
*/10 in the minute field expands to 0, 10, 20, 30, 40 and 50. The remaining four fields
are wildcards, so those six minutes are matched in every hour of every day. Ten divides cleanly into
sixty, which is why the interval stays even across the hour boundary — something intervals like
*/7 or */45 cannot claim.
Why 10 minutes is often the right choice
Ten minutes is long enough that a job taking a minute or two has ample headroom, and short enough that a failure is noticed within a single monitoring window. It is a common cadence for metric aggregation, queue drains, mailbox polling and incremental index updates.
If the work is idempotent and cheap, moving from */5 to */10 halves the
load for very little loss in freshness. If the work is expensive, consider whether an event or a webhook
would serve better than polling at all.
Using it
# crontab, with a lock so runs cannot overlap
*/10 * * * * /usr/bin/flock -n /tmp/agg.lock /usr/local/bin/aggregate.sh# Kubernetes CronJob
spec:
schedule: "*/10 * * * *"
timeZone: "Etc/UTC"
successfulJobsHistoryLimit: 3Restricting it to part of the day
Wildcards in the hour field mean the job also runs all night. If that is wasteful, narrow it:
| Expression | Runs |
|---|---|
| */10 * * * * | Every 10 minutes, 144 times a day. |
| */10 8-20 * * * | Every 10 minutes from 08:00 to 20:59. |
| */10 * * * 1-5 | Every 10 minutes, weekdays only. |
| */10 9-17 * * 1-5 | Every 10 minutes during office hours on weekdays. |
| 5-55/10 * * * * | Every 10 minutes, offset to :05, :15, :25 and so on. |
Remember that an hour range such as 8-20 includes the whole of hour 20, so the last run
is at 20:50.
Restricting the day-of-month field as well as the weekday one, rather than just the weekday, invokes cron's day-of-month/day-of-week OR rule — the single most common cron misunderstanding, and worth reading before you rely on a combined restriction.