Every 15 minutes
The step-value schedule for polling, health checks and sync jobs: */15 fires on the quarter hour, around the clock.
Last updated
In plain English
- Fires at :00, :15, :30 and :45
- 96 runs per day
Why it’s written this way
*/15 in the minute field means "every value divisible by 15": minutes 0, 15, 30 and 45 of every hour. The other four stars leave hour, day and month unconstrained.
Steps divide the field's own range, which is why they read so cleanly for 5, 10, 15, 20 and 30 — the divisors of 60.
Edge cases to know
- →*/17 does NOT mean "every 17 minutes" — it means minutes 0, 17, 34, 51, then a 9-minute gap to the next hour's 0. Steps reset at the field boundary.
- →All instances of a fleet fire at the same instant; add a random sleep (or use systemd timers' RandomizedDelaySec) if a thundering herd matters.
- →For sub-minute schedules cron is the wrong tool — use a loop or a timer service.
Part by part
- */15
- A step value in the minute field: starting at 0, every fifteenth minute — so 0, 15, 30 and 45. It is shorthand for the list 0,15,30,45, not a rolling fifteen-minute timer.
- * * * *
- Hour, day-of-month, month and day-of-week, all unrestricted. Four wildcards are what turn a per-hour pattern into an always-on one.
Common mistakes
*/15 * * * 1-5Adding a weekday restriction is often what people actually want, but it is worth writing deliberately rather than discovering later that the job also ran all weekend — or did not.
15 * * * *Without the asterisk and slash this is not a step at all: it means minute 15 of every hour, so the job runs once an hour instead of four times. The two forms differ by two characters and by a factor of four.
*/15 * * * **/15 */1 * * *A step of one in the hour field is the same as a wildcard, so this adds a second unit of complexity for no behavioural change. It reads as if something clever is happening when nothing is.
Questions
Does it run fifteen minutes after the previous run finishes?
No. Cron fires at fixed points on the clock, not on an interval measured from the last completion. If a run takes twenty minutes, the next one starts while it is still going rather than waiting.
What happens if a run overlaps the next one?
Cron starts it anyway, and you end up with two copies competing. Wrap the command in flock, or have the script take a lock file and exit if one is already held — this is the single most common cause of a duplicated job.
Does */7 work the same way for seven minutes?
It runs at 0, 7, 14, 21, 28, 35, 42, 49 and 56 past the hour — and then the gap to the next hour's zero is only four minutes. Steps that do not divide 60 evenly produce an uneven cycle at every hour boundary.
Is this too frequent for a shared server?
It depends entirely on what the job does, but ninety-six runs a day of anything expensive adds up. If the work is usually a no-op, make the script exit early and cheaply rather than reducing the frequency and adding latency.