Cron every 5 minutes
Expression: */5 * * * * — Every 5 minutes.
Every 5 minutes
Next 5 runs in UTC, from 1 Jan 2026 (example)
When to use it
The step syntax */5 means "every fifth value of the minute field", so the job starts at minutes 0, 5, 10 and so on up to 55 — twelve times an hour, 288 times a day. The runs are aligned to the wall clock, not to the moment you saved the crontab: a line added at 10:03 first fires at 10:05. That alignment is what most teams want for polling an external API, refreshing a cache, sending batched notifications or collecting metrics from devices that report on a fixed cadence.
Field by field
| Field | Value | Meaning |
|---|---|---|
| Minute | */5 | every 5th minute: 0, 5, 10 … 55 |
| Hour | * | every hour |
| Day of the month | * | every day of the month |
| Month | * | every month |
| Day of the week | * | every day of the week |
Real-world example
*/5 * * * * curl -fsS --max-time 20 https://example.com/internal/refresh-cache
Refreshes a cache every five minutes. --max-time stops a hung request before the next run starts, and -f makes HTTP errors fail the job so they show up in logs.
Variants
| Expression | Meaning |
|---|---|
2-59/5 * * * * | At minute 2-59/5 past hour *, every day — same rate, shifted to minute 2, 7, 12… to avoid the top-of-hour rush |
*/5 8-18 * * * | Every 5 minutes during hours 8-18 — only between 08:00 and 18:59 |
0,30 * * * * | At minute 0,30 past hour *, every day — twice an hour instead, if five minutes is more often than needed |
Pitfalls
- */5 in the hour field means every five hours, not minutes — check which column you edited before saving.
- Thousands of servers run */5 jobs in the same second. Offset with 1-59/5 or 2-59/5 to spread load on shared APIs and databases.
- GitHub Actions does not guarantee five-minute schedules: under load, runs are delayed or dropped, so do not rely on it for tight timing.
Questions
What happens if the server is down at the scheduled minute?
Classic cron does not catch up; missed runs are simply lost. Anacron and systemd timers with Persistent=true can replay a missed execution after boot, which matters for jobs that must happen at least once.
Why did my first run happen sooner than five minutes after saving?
Steps are aligned to the clock. Saving at 10:03 means the next matching minute is 10:05, two minutes later, not 10:08.
How do I run every 5 minutes only on business days?
Restrict the weekday field: */5 * * * 1-5. Add an hour range such as 8-18 in the second field to limit it to office hours as well.
The same schedule elsewhere
- GitHub Actions:
on: schedule: - cron: '*/5 * * * *'. Always UTC, and runs can start several minutes late when runners are busy. - Kubernetes CronJob:
schedule: "*/5 * * * *"; setconcurrencyPolicy: Forbidto prevent overlapping pods andtimeZoneif you need local time. - Cloudflare Workers:
crons = ["*/5 * * * *"]under[triggers]in wrangler.toml, evaluated in UTC.
Before you deploy
Use absolute paths, because cron starts commands with a minimal PATH and without your shell profile. Make the job idempotent so a late or repeated run does no harm, log its exit code, and let a dead-man's-switch monitor alert you when an expected run never happens.