Every 5 minutes
A steady polling cadence for health checks, syncs and queue drains: */5 fires twelve times an hour, on every multiple of five.
Last updated
In plain English
- Fires at :00, :05, :10 ... :55 of every hour
- 288 runs per day
Why it’s written this way
*/5 in the minute field expands to every value from 0 through 59 divisible by 5 — :00, :05, :10 … :55, twelve firings an hour. The remaining four fields stay *, so it runs every hour of every day.
This is cron's step-value shorthand: */n is equivalent to spelling out 0,5,10,15,... by hand, but it stays correct even if the field's usable range ever changed.
Edge cases to know
- →Twelve clean runs an hour only works because 5 divides 60 evenly; a badly chosen step like */7 drifts through the hour and resets at the top of the next one instead of repeating a fixed interval.
- →If the job can take longer than 5 minutes under load, two copies can overlap — add a lockfile (flock) or a mutex before pushing the frequency any higher.
- →Every server in a fleet running this fires at the same wall-clock second; for anything hitting a shared downstream service, jitter the start with a short random sleep.
Part by part
- */5
- A step in the minute field: 0, 5, 10 and so on to 55. Twelve runs an hour, at fixed points on the clock rather than five minutes apart from each other.
- * * * *
- Hour, day-of-month, month and day-of-week all open, which is what makes the schedule continuous rather than confined to a window.
Common mistakes
0,5,10,15,20,25,30,35,40,45,50,55 * * * *Correct and unreadable. The step form says the same thing in three characters, and a list this long invites a typo that nobody will spot in review.
*/5 * * * **/5 * * * * in a Docker containerMost base images ship no cron daemon at all, so the crontab is installed and never runs. Container schedules belong in the orchestrator — a Kubernetes CronJob or an ECS scheduled task — rather than inside the image.
*/5 * * * * curl https://example.com/cronTriggering work over HTTP without a timeout means a hung request holds the process indefinitely, and five minutes later another starts. Add --max-time and check the exit code.
Questions
How do I know the job is still running at all?
A dead man's switch: have the job ping a monitoring URL on success, and let that service alert when a ping does not arrive. Cron reports failures to nobody, so silence and success look identical without one.
Do all my servers run this at the same instant?
Yes, if their clocks agree — which is the point of NTP. A fleet of twenty machines all calling the same API at :00 and :05 is a self-inflicted load spike, so stagger the minute per host.
What does the job inherit from my shell?
Very little. No profile is sourced, so PATH is minimal and none of your environment variables exist. Anything the job needs must be set in the crontab itself or sourced explicitly at the top of a wrapper script.
Should this be a systemd timer instead?
On a modern Linux host it is worth considering: timers log to the journal, handle overlap explicitly, support randomised delays, and report failure status. Cron wins on portability and on being already there.