Cron Expression for Every 5 Minutes
*/5 * * * **/5 * * * * runs at every minute divisible by 5: :00, :05, :10 and so on. The step counts from the start of the hour, not from when the job was installed, so all */5 jobs across your fleet fire at the same instants.
Next runs, in your timezone
What */5 actually means
The step operator divides the minute field's range. */5 expands to 0,5,10,…,55 — minutes divisible by 5 — not "five minutes after the previous run". If the job takes longer than five minutes, the next fire still happens on time and the two runs overlap; guard with a lock if the job is not safe to run concurrently.
*/5 * * * * flock -n /tmp/myjob.lock /path/to/job.sh >> /var/log/myjob.log 2>&1Offsetting the schedule
Because every */5 job in the world fires at the same minutes, shared resources see synchronized spikes. Start the range later to offset: 2-57/5 fires at :02, :07, :12 … :57 — same cadence, quieter minutes.
2-57/5 * * * * /path/to/job.shScheduler differences
Standard 5-field cron (Linux crontab, Kubernetes CronJob, Vercel) accepts this as-is. GitHub Actions also accepts it but treats 5 minutes as its minimum interval and often delays runs under load. AWS EventBridge uses a 6-field syntax with a year field, written cron(0/5 * * * ? *).
Equivalent expressions
0,5,10,15,20,25,30,35,40,45,50,55 * * * *— the explicit list */5 expands to — identical schedule2-57/5 * * * *— same cadence offset to :02, :07, … to avoid the synchronized-minute stampede
Run a SQL query on this schedule
If the job behind this schedule is a database query, you can skip the server and the crontab: SaturnSQL runs saved SQL queries on a cron expression — this exact syntax, with a real timezone field — and delivers the results to Google Sheets or Slack. Minimum interval 5 minutes.