Cron Job Every 5 Minutes: Syntax and Examples

By CronHub Tools · Updated 2026-08-04

To run a cron job every 5 minutes, use this expression:

*/5 * * * * /path/to/your/command

That's the complete answer. The */5 in the minute field tells cron to fire at minutes 0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, and 55 of every hour — 288 runs per day, like clockwork.

Now let's make sure it actually works in practice: how the step value operates, how to adapt it to other intervals, and the overlap trap that catches people running frequent jobs.

How */5 Works

Cron's five fields are minute, hour, day of month, month, and day of week. The slash creates a step value: */5 in the first field means "every 5th minute, starting from 0."

*/5 * * * *  command
 │  │ │ │ └─ any day of week
 │  │ │ └─── any month
 │  │ └───── any day of month
 │  └─────── any hour
 └────────── minutes 0,5,10,...,55

Two details worth knowing:

• Steps are clock-aligned, not run-aligned. The job fires at fixed minutes (0, 5, 10…), not "5 minutes after the previous run finished."
• */5 is shorthand for a list. It behaves exactly like writing 0,5,10,15,20,25,30,35,40,45,50,55.

Adding a Job That Runs Every 5 Minutes

Open your crontab and add the line:

crontab -e

*/5 * * * * /home/user/scripts/sync.sh >> /home/user/logs/sync.log 2>&1

The redirection at the end matters more for frequent jobs than for daily ones. A job that runs 288 times a day and emails its output will bury your local mailbox by lunch — log to a file instead.

Verify the entry saved:

crontab -l

Then confirm it fires by checking the log after five minutes, or watching the system log:

grep CRON /var/log/syslog | tail   # Debian/Ubuntu
journalctl -u cron -n 20           # systemd systems

Common Cron Intervals (Adapting the Pattern)

Once you understand */5, every other cron interval is the same trick with a different number:

One caution: */23 or other numbers that don't divide 60 evenly produce uneven gaps. */23 fires at minutes 0, 23, and 46 — then the next run is at minute 0 again, only 14 minutes later. Stick to divisors of 60 (1, 2, 3, 4, 5, 6, 10, 12, 15, 20, 30) for truly regular intervals.

Every 5 Minutes, But Only Sometimes

Step values combine cleanly with the other fields:

# Every 5 minutes during business hours, weekdays only
*/5 9-17 * * 1-5 /home/user/scripts/poll.sh

# Every 5 minutes, but only between minute 0 and 30 of each hour
0-30/5 * * * * /home/user/scripts/burst.sh

The second example shows a step applied to a range: 0-30/5 fires at 0, 5, 10, 15, 20, 25, 30 — then rests until the next hour.

The offset gotcha

*/5 always starts from 0. If you want runs at 2, 7, 12, 17… (say, to avoid competing with another job at minute 0), a step value cannot express that. List the minutes explicitly:

2,7,12,17,22,27,32,37,42,47,52,57 * * * * /home/user/scripts/offset.sh

The Overlap Trap (and How flock Fixes It)

Here's the problem nobody warns you about: cron starts a new run every 5 minutes whether or not the previous run finished. If your script occasionally takes 6 minutes — a slow API, a big file, a locked database — two copies run at once. Then three. Eventually the server is grinding under a pile of stacked processes.

The standard fix is flock, which takes a lock file and skips the run if the lock is already held:

*/5 * * * * /usr/bin/flock -n /tmp/sync.lock /home/user/scripts/sync.sh >> /home/user/logs/sync.log 2>&1

The -n flag means "don't wait — if a previous run still holds the lock, exit immediately." For any job on a 5-minute cron interval that touches a network or database, treat flock as mandatory.

Is Every 5 Minutes the Right Frequency?

Before committing to 288 runs a day, sanity-check the need. Polling an API every 5 minutes that updates hourly wastes 91% of the calls — and may hit rate limits. On shared hosting, aggressive schedules can violate the provider's terms. And each run costs a process spawn, log growth, and a slot in your monitoring. A quick rule of thumb: match the cron interval to how fast the underlying data actually changes, then add one notch of slack. If 10 minutes is genuinely fine, */10 halves the noise for free.

Common Mistakes

1. Writing 5 * * * * instead of */5 * * * *. The first runs once per hour at minute 5 — a completely different schedule.
2. Skipping output redirection. 288 daily emails to the local user, or output silently discarded. Neither helps you.
3. No overlap protection. See above — use flock.
4. Relative paths. Cron's environment is minimal; ./sync.sh won't resolve. Use full paths for the script and everything inside it.
5. Using cron for sub-minute needs. Cron's floor is one minute. If you need every 30 seconds, run a small loop under systemd or a proper scheduler instead of hacking cron.

Conclusion

Running a cron job every 5 minutes comes down to one expression — */5 * * * * — plus two habits that keep it healthy: redirect the output to a log, and wrap the command in flock -n so runs never stack up. Swap the 5 for any divisor of 60 and you've mastered every common cron interval in one go.

For the full picture of how step values, ranges, and lists fit together, read our cron syntax guide — or check the troubleshooting guide if your every-5-minutes job isn't firing.

Frequently Asked Questions

Related guides

References

• crontab.guru — */5 * * * * — interactive confirmation of the schedule
• man7.org — crontab(5) manual page — step value specification
• util-linux — flock(1) manual page — preventing overlapping runs