Quarter-hourly, off the herd
Same cadence as */15, shifted 7 minutes off the beat — so this job never competes with everyone else's :00, :15, :30 and :45 jobs.
Last updated
In plain English
- Fires at :07, :22, :37 and :52 of every hour
- 96 runs per day
Why it’s written this way
7,22,37,52 is an explicit comma list rather than a step: four fixed minutes, each 15 apart, offset from the usual :00/:15/:30/:45 grid most cron jobs default to. The other four fields stay *, so it repeats every hour.
A step value like */15 would have been shorter to write, but it always lands on multiples of 15 counted from zero — there's no way to make */15 start at :07 instead. An explicit list is the only way to keep the interval while shifting its phase.
Edge cases to know
- →This solves the 'thundering herd' problem: if every job on a shared host or downstream API fires at :00, :15, :30 and :45, adding a fixed offset spreads the load without changing how often the job runs.
- →The offset only helps if OTHER jobs are actually sitting on the standard grid; on a host where everything is already staggered, this just adds one more arbitrary time to keep track of.
- →Four explicit minutes are harder to read at a glance than */15 — a comment on the crontab line explaining why it's offset saves the next person from 'simplifying' it back onto the grid.
Part by part
- 7,22,37,52
- An explicit list fifteen minutes apart, deliberately offset from the quarter-hour marks. The offset is the entire point of the schedule.
- * * * *
- Every hour, every day. The frequency matches */15 exactly — only the phase differs.
Common mistakes
*/15 * * * *Behaves identically in frequency and lands on 0, 15, 30 and 45 — where every other default schedule on the machine and across the fleet also lands. That synchronisation is what this recipe exists to avoid.
7,22,37,52 * * * *7-52/15 * * * *A stepped range starting at 7 gives 7, 22, 37 and 52, which is the same set — and it stops at 52 rather than wrapping, so a reader has to check whether anything past 52 was intended. The list states it plainly.
Using the same offset on every hostIt moves the herd rather than dispersing it. If the reason is fleet-wide load, the offset should differ per machine — derived from the hostname, or set at provisioning time.
Questions
Why does the offset matter?
Because everything defaults to the top of the hour and the quarter marks, so those minutes carry a disproportionate share of the load — on your machine, on shared infrastructure, and at whatever API you are calling.
Does the exact offset matter?
Only that it is not a round number. Seven is as good as eleven; what matters is avoiding 0, 15, 30 and 45, and ideally differing from whatever your neighbours picked.
How do I spread a fleet automatically?
Derive the minute from a hash of the hostname when the crontab is generated, so each machine gets a stable but different offset. Configuration management makes this a two-line template.
Is there a built-in way to randomise?
Not in classic cron. anacron has RANDOM_DELAY and systemd timers have RandomizedDelaySec, both of which do this properly. In cron the offset has to be chosen when the line is written.