What is the cron expression for every 5 minutes?

The cron expression for every 5 minutes is "*/5 * * * *". Runs at minute 0, 5, 10 … 55 of every hour.

What should I watch out for when running a cron job every 5 minutes?

*/5 counts from minute 0 of the hour — runs land at :00, :05, :10… regardless of when you installed the job. It does not mean “5 minutes after the last run finished”. Thundering herd: half the internet’s crons fire exactly at :00 and :05. If you hit a shared API, add a jitter like sleep $((RANDOM % 60)) at the top so you’re not in the spike.

Cron expression for Every 5 minutes

*/5 * * * *

Runs at minute 0, 5, 10 … 55 of every hour.

Next 5 runs (your local time)

These are shown in your browser’s timezone. The job itself runs in the scheduler’s timezone — often UTC — so the real run time can differ.

What people actually schedule with `/5 * * *`

Health checks and uptime pings against your own services
Draining messages from a queue in small batches
Refreshing a dashboard cache, exchange rates, or feature flags

Use `/5 * * *` on your platform

It’s the same 5-field expression everywhere — what changes is where you put it and which timezone it runs in.

Linux / crontab

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

Runs in the server’s local timezone — check it with timedatectl. Full field reference: crontab(5) man page.

GitHub Actions

on:
  schedule:
    - cron: "*/5 * * * *"

GitHub Actions always runs scheduled jobs in UTC — there is no timezone setting, and runs can be delayed under load (official docs).

Kubernetes CronJob

spec:
  schedule: "*/5 * * * *"

Defaults to UTC. Set spec.timeZone (Kubernetes 1.27+) for a specific zone — see the CronJob docs.

Quartz / Spring `@Scheduled`

Quartz uses 6 fields (seconds first): 0 */5 * * * *. Watch out: Quartz day-of-week is 1=SUN … 7=SAT (not 0–6), and day-of-month / day-of-week use ? — double-check if your schedule touches those fields (Quartz cron reference).

Gotchas with every 5 minutes schedules

*/5 counts from minute 0 of the hour — runs land at :00, :05, :10… regardless of when you installed the job. It does not mean “5 minutes after the last run finished”.
Thundering herd: half the internet’s crons fire exactly at :00 and :05. If you hit a shared API, add a jitter like sleep $((RANDOM % 60)) at the top so you’re not in the spike.
On GitHub Actions this is the shortest interval worth writing — and under load the real cadence drifts to 7–10 minutes. Don’t build SLAs on it.

Will you know if this job silently fails?

Cron jobs fail quietly — a server reboots, a path changes, or an error code is ignored — and nobody notices until the data is missing. A cron monitor (a dead-man’s-switch) alerts you when a scheduled job does not check in on time.

Monitor your cron jobs with UptimeRobot →

Disclosure: this is an affiliate link — we may earn a commission if you sign up, at no extra cost to you.

Is `/5 * * *` the right schedule?

Tighter loops belong on every minute (with locking). If the data source itself only updates a few times an hour, every 15 minutes is free money — 3× fewer runs, same freshness.

Or use the interactive cron generator & explainer, read the complete cron syntax guide, or pick another common schedule: