* CronBuilder

Cron expression for every 5 minutes

The schedule is */5 * * * *. It is preloaded below — check the next run times in your own timezone.

Presets

Every 5 minutes.

Build field by field

0-59
every
0-23
1-31
1-12 / JAN-DEC
0-7 / SUN-SAT

Next 5 run times

Computing in your browser…

Next-run times are computed in your browser’s local timezone; daylight-saving shifts follow your OS clock. A server in another timezone (or UTC) will fire at different wall-clock times.

How */5 * * * * works

The first field is the minute, and */5 means “every value in 0–59 that is reachable in steps of 5 starting from 0”: 0, 5, 10 … 55. The remaining four fields are all *, so the rule applies in every hour, every day, every month, every weekday. That gives you 12 runs per hour and 288 runs per day.

A detail that trips people up: the step is anchored to the clock, not to the moment you created the job. Cron never remembers “last ran at” — each minute it simply asks “does the current time match?”. So */5 always fires at :00, :05, :10 and so on, regardless of when the crontab was saved. If you truly need “5 minutes after the previous run finished”, cron alone cannot express that; you would loop with sleep inside a long-running process instead.

Useful variants

ExpressionMeaning
*/5 * * * *Every 5 minutes, around the clock
2-57/5 * * * *Every 5 minutes, offset to :02, :07, :12 … (avoids the :00 stampede)
*/5 9-17 * * 1-5Every 5 minutes during business hours, weekdays only
*/10 * * * *Every 10 minutes
*/15 * * * *Every 15 minutes (quarter-hourly)
0,30 * * * *Every 30 minutes, on the hour and half hour

The offset variant matters more than it looks: a huge share of the world’s cron jobs fire at minute 0 and at :05-style marks, so APIs and databases see load spikes on those boundaries. Shifting your polling job to 2-57/5 keeps the 5-minute cadence while dodging the crowd.

Overlap: the classic every-5-minutes bug

If the job occasionally takes six minutes, cron will happily start the next instance while the previous one is still running. Two copies of a sync script writing to the same rows is a subtle way to corrupt data. The standard fix on Linux is a non-blocking lock in the crontab line itself:

*/5 * * * * flock -n /tmp/sync.lock /usr/local/bin/sync.sh

With -n, the new instance exits immediately if the lock is held, effectively skipping a beat instead of overlapping. Alternatively, have the script create and check its own PID file.

Is every 5 minutes the right frequency?

For health checks and queue pollers it is a common default. But if you find yourself lowering it further (every minute, every 30 seconds), cron is usually the wrong tool — standard cron cannot go below one minute at all. At that point look at a message queue, webhooks, or a supervised long-running worker. Conversely, if the data only changes hourly, an hourly schedule saves 11 out of every 12 runs.

FAQ

What is the cron expression for every 5 minutes?

*/5 * * * * — the */5 step in the minute field matches minutes 0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50 and 55, in every hour of every day.

Does */5 mean "5 minutes after the job starts"?

No. Steps are anchored to the clock, not to when you installed the job. */5 fires at wall-clock minutes divisible by 5. If you save the crontab at 10:03, the first run is 10:05, then 10:10, and so on.

How do I run every 5 minutes only during business hours?

Combine the minute step with an hour range: */5 9-17 * * 1-5 runs every 5 minutes from 09:00 through 17:55, Monday to Friday. Note the hour range is inclusive, so the last run of the day is 17:55.

What if a run takes longer than 5 minutes?

Cron does not wait — it starts a new instance on schedule, so runs can overlap. If your job must not overlap, guard it with a lock, e.g. flock -n /tmp/job.lock on Linux, or check a PID file at the top of the script.

Related: cron every hour · cron every day at midnight · full cron expression generator