Type “cron every 5 minutes” into a search box and every result hands you the same line:

*/5 * * * *

It works — but why it works, where it’s anchored, and what its look-alikes actually do is where the bugs live. Here’s the short version plus the variants worth knowing.

What */5 actually expands to

The minute field takes values 0–59, and */n means “every n-th value, starting at the field’s minimum.” So */5 is the set {0, 5, 10, 15, …, 55} — twelve fixed minute marks inside each hour:

:00  :05  :10  :15  :20  :25  :30  :35  :40  :45  :50  :55   → 288 runs/day

Two consequences people miss:

• It’s clock-aligned, not a stopwatch. Install the line at 14:32 and the first run is 14:35 — cron matches wall-clock minutes, it doesn’t start a five-minute countdown from when you saved the file.
• The step counts from the range start. */5 is shorthand for 0-55/5 — same set, longer spelling.

That second rule produces the subtle variant:

5/5 * * * *     → minutes {5,10,15,…,55} — NO :00 run

5/5 means “start at 5, step to the field max” (the Vixie a/n = a–max/n rule). It differs from */5 in exactly one minute: :00. If you want “every 5 minutes, offset by 2” — say, to dodge a fleet of other jobs that all fire on :00/:05 — write the range out:

2-57/5 * * * *  → :02 :07 :12 :17 :22 :27 :32 :37 :42 :47 :52 :57

The variants people actually need

expression	what it does
*/5 * * * *	every 5 minutes, always
*/5 * * * 1-5	every 5 minutes on weekdays (Mon–Fri)
*/5 9-17 * * 1-5	every 5 min, 09:00–17:55, weekdays
*/5 2-4 * * *	every 5 min, only 02:00–04:55
*/5 * 1 * *	every 5 min, on the 1st of each month
*/5 * * jan *	every 5 min, all of January
2-57/5 * * * *	every 5 min, offset two minutes off the marks
0,5,10,15,20,25,30,35,40,45,50,55 * * * *	*/5 the long way — identical set

The hour window rows deserve a note: */5 9-17 fires :00–:55 inside each hour 9 through 17 — the last run is 17:55, not “5 minutes past 17:00 only”. The hour field restricts which hours participate; the minute step still fills them.

The three look-alikes that aren’t

5 * * * * — hourly at :05, 24 runs/day. Dropping the / turns “every 5 minutes” into “5 minutes past every hour”. If a job runs suspiciously rarely, check for a missing slash.

* */5 * * * — every minute of hours {0,5,10,15,20}, 300 runs/day. This is the “every 5 hours” attempt, and it does something much more aggressive: the minute * runs every minute within the stepped hours — five bursts of 60 runs across the day. There is no “every N hours” step that means what people expect in one field; write the hour list (0 */5 * * * → 00:00, 05:00, 10:00, 15:00, 20:00) when you want one shot per stepped hour.

* * */5 * * — days {1,6,11,16,21,26,31}, not “every 5 days”. Day-of-month steps count from 1 (the field minimum), so the marks sit on day 1, 6, 11… — not aligned to anything you’d guess — and 31 silently never fires in the five short months. The calculator flags both facts with a chip.

And a bonus trap for non-divisors: */7 gives {0,7,14,…,56} — the last mark is :56, then the next hour restarts at :00, so the real intervals are 7,7,7,…,4 minutes at the hour boundary. Steps that don’t divide 60 have a shorter tail gap; only 1,2,3,4,5,6,10,12,15,20,30 divide cleanly.

Operational notes at 288 runs/day

Every-5-minutes is the frequency where cron’s honesty problems start to matter:

• Overlaps. A job that occasionally runs long piles onto itself — flock -n /tmp/job.lock on the line keeps one instance (details).
• Log volume. 288 mail lines or log lines a day is why MAILTO inboxes get abandoned — redirect deliberately.
• Sub-minute is impossible. Cron’s granularity is one minute; for tighter intervals see systemd timers (OnUnitActiveSec=30s) or a supervised loop.
• Jitter for fleets. If a hundred servers each run */5, they all hit the same minutes — offset with 2-57/5-style shifts or a random sleep in the command.
• Timezone belongs to the server. */5 is timezone-proof (every five minutes is every five minutes in every zone), but the moment you add hours or weekdays — */5 9-17 * * 1-5 — the schedule is in the server’s clock. The calculator’s list is in your browser’s; reconcile the two before trusting it.

Paste any of these into the calculator to see the next run times in your own timezone — and if a day field is involved, read the dom/dow OR rule before it surprises you.

Frequently asked questions

Does */5 * * * * really mean every 5 minutes?

Yes — 288 times a day, at :00, :05, :10 … :55 of every hour. The key detail: it's aligned to the clock, not to when you saved the crontab. If you install the line at 14:32:20, the first run is 14:35, not 14:37.

What's the difference between */5 and 5 * * * *?

Everything. */5 * * * * = every 5 minutes (288 runs/day). 5 * * * * = once per hour, at 5 minutes past (24 runs/day). The single most common swap in crontab history — the step needs the /.

How do I run every 5 minutes only on weekdays?

*/5 * * * 1-5 — minute field steps, day-of-week restricts to Mon–Fri. For office hours too: */5 9-17 * * 1-5 = every 5 minutes between 09:00 and 17:55, weekdays only.

Can cron do every 5 seconds (or any sub-minute interval)?

No — cron's smallest unit is the minute. For sub-minute you need a loop (while true; do job; sleep 5; done, preferably under a supervisor), a systemd unit with OnUnitActiveSec=5s, or a watchdog. Spawning 12 one-minute cron jobs with sleeps is the fragile hack.

Why did my every-5-minutes job overlap itself?

Cron fires on schedule whether or not the previous run finished — a job that occasionally takes 6+ minutes piles up. Guard with a lock: */5 * * * * flock -n /tmp/job.lock /opt/job.sh — more in debugging cron.

Is */5 the same as 0,5,10,15,20,25,30,35,40,45,50,55?

Identical — */5 in the minute field expands to exactly that set. The list form just takes 34 characters to say it.