The cron expression for every 5 minutes is */5 * * * *. Put it in front of your command in a crontab and the job fires at minute 0, 5, 10 and so on through 55, every hour of every day.
That is the whole answer for standard Linux cron. The rest of this guide covers how to check it before you trust it, the variants people usually need next, and the traps that make a five-minute job run at the wrong time or not at all.
Reading */5 * * * * field by field
A classic crontab line has five time fields, separated by spaces, then the command.
| Position | Field | Value here | Meaning |
|---|---|---|---|
| 1 | Minute (0-59) | */5 |
Every fifth minute, starting at 0 |
| 2 | Hour (0-23) | * |
Every hour |
| 3 | Day of month (1-31) | * |
Every day |
| 4 | Month (1-12) | * |
Every month |
| 5 | Day of week (0-7) | * |
Any weekday |
The slash is a step value. * means the full range, and /5 takes every fifth value from it. The crontab(5) manual page documents the same syntax: asterisks, ranges with a hyphen, lists with commas and steps with a slash.
Check it before it ships
Pasting a schedule into production and waiting to see what happens is a slow way to find a typo. Open the AyeTab cron expression parser, type */5 * * * *, and it answers in plain English ("Every 5 minutes") and lists the next run times in UTC. Try it again with one character changed to see the difference between */5 and 5 (which means only at minute 5, once an hour).
The parser runs in your browser tab. Nothing you type is uploaded, there is no account, and it is free. If you work in Chrome, the AyeTab extension puts the same tool on your new tab page, one Ctrl+K away.
Close variants you will need next
| You want | Expression |
|---|---|
| Every 5 minutes, only during working hours | */5 9-17 * * * |
| Every 5 minutes on weekdays | */5 * * * 1-5 |
| Every 5 minutes, offset to minutes 2, 7, 12 | 2-59/5 * * * * |
| Every 10 minutes | */10 * * * * |
| Every 15 minutes | */15 * * * * |
The offset form is handy when many jobs share a server. If every team picks */5, they all start at the same second and compete for CPU. Shifting yours by a couple of minutes spreads the load.
Common mistakes with five-minute jobs
Writing 5 * * * *. That runs once an hour, at five past. The step needs the slash.
Forgetting the time zone. Cron uses the server's clock. The crontab.guru tips page recommends running servers in UTC, and AyeTab lists its next runs in UTC too. A UTC clock keeps daylight saving changes out of the schedule.
Overlapping runs. If a job sometimes takes longer than five minutes, the next one starts on top of it. Wrap the command with a lock, for example flock -n /tmp/job.lock your-command, so a second copy exits instead of piling up.
Expecting seconds. Standard cron has no seconds field. Schedulers that use the Quartz format, such as many Java apps, put seconds first, so their five-minute expression is 0 0/5 * * * ?. Check which format your platform expects before you copy a line from a forum.
A quick test routine
Before you commit a new schedule, run through the same three checks every time. First, read the expression back in plain English and make sure the sentence matches the ticket. Second, look at the next few run times and ask whether any of them lands somewhere awkward, such as during a deploy window or a nightly backup. Third, compare the server clock with your own: run date on the box, and if it reports UTC, read the parser's UTC times as they are. Together this takes under a minute and catches most scheduling bugs before they reach a server.
When another tool fits better
If you want a browsable list of ready-made schedules, crontab.guru has an examples page with a long list of them. For checking the expression you actually wrote, AyeTab is quicker and keeps the input on your machine.