Cron Every 5 Minutes

A cron expression that runs every 5 minutes:

*/5 * * * *

This fires at :00, :05, :10, :15, :20, :25, :30, :35, :40, :45, :50, :55 of every hour — 12 times per hour, 288 times per day. The page above generates the schedule; this companion explains the cadence and its tradeoffs.

How */5 works

The / is the step operator. */5 in the minute field means “every 5 minutes from minute 0 of the hour.” The schedule:

*/5  =  0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55

Equivalent to writing them all out:

0,5,10,15,20,25,30,35,40,45,50,55 * * * *

5 divides 60 evenly, so the spacing is uniform across hour boundaries. The last minute of one hour (:55) is exactly 5 minutes before the first minute of the next (:00 of the next hour).

When 5 minutes is the right cadence

• Polling third-party APIs. Below 5 minutes, rate limits become a concern; above 5 minutes, the data is stale.
• Frequent sync between systems. Databases that need to mirror state from upstream sources where event-driven sync isn’t available.
• Health checks at moderate sensitivity. Detect a service outage within 5 minutes without paging on transient blips.
• Short-window aggregations. 5-minute rollups are a common bucket size in metrics and observability.
• Retry orchestration. A failed job that retries on a 5-minute cadence has 12 attempts per hour — usually plenty.

When 5 minutes is the wrong cadence

• The job takes more than 5 minutes. Overruns. Either run less frequently or guard against overlap.
• The cost per run is high. At 288 runs per day, even small per-run costs (a few seconds of CPU, a database query) compound. Audit total cost before adopting */5.
• You actually want event-driven. If something downstream creates the work, listening for events is cleaner than polling. Cron is the fallback for systems without event support.
• Real-time matters. A 5-minute lag is meaningful in user-facing context. For sub-minute SLAs, cron isn’t the tool.

Variants

*/5 * * * *            ← every 5 minutes, all day
*/5 9-17 * * 1-5       ← every 5 min, 9 AM–5 PM, weekdays
*/5 0,12 * * *         ← every 5 min only at midnight and noon hours
1-59/5 * * * *         ← :01, :06, :11, ... — offset start

The third example is one of the common confusions: 0,12 in the hour field with */5 minute means “every 5 minutes during midnight hour and noon hour” — only 24 fires per day, not 288.

Comparison with neighboring cadences

5 minutes is roughly the sweet spot for “as fast as cron should be polling.” Anything more frequent strains the model and you should consider event-driven alternatives.

Common pitfalls

• Overlapping runs. A 5-minute job that sometimes takes 6 minutes overlaps with itself. Wrap with flock /var/lock/myjob.lock -n my-script to no-op the second instance.
• Cron daemon overhead. Each */5 job adds a row to the per-minute fire check. Hundreds of */5 jobs on one host don’t break cron, but they make the timing-critical job harder to reason about.
• Quiet errors. A job firing 288 times a day that fails silently piles up problems faster than someone notices. Wire up basic error reporting (cron mailing on stderr, alerting on no-success-in-N-fires).
• Jitter for thundering herd. All */5 jobs on different hosts fire at the same minutes. If they all hit a shared API, you get spikes. Stagger with 2-59/5 * * * * (:02, :07, :12, ...) or use RandomizedDelaySec on systemd timers.

For more or less frequent schedules, see cron every minute and cron every 15 minutes. For the cron grammar, see cron expression generator.