Cron Expression for Every 5 Minutes: */5 * * * *

The */5 * * * * Expression

The cron expression */5 * * * * schedules a job to run every 5 minutes, every hour, every day. The five fields map to: minute, hour, day of month, month, day of week. A * in a field means “every valid value.” The */5 in the minute field uses the step operator to select every 5th value.

The Step Operator

The / character in cron is called the step operator. The syntax */N means “every N units across the full range.” For the minute field:

• Full range: 0 to 59
• Step: 5
• Result: 0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55

You can also use a step on a restricted range. 10-30/5 expands to 10,15,20,25,30, firing every 5 minutes, but only within the 10-to-30 window. This is less commonly needed but valid in all major cron implementations.

What This Expands To

*/5 * * * *

Is exactly equivalent to:

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

Both forms fire 12 times per hour, 288 times per day. If you paste either into crontab -e on a Linux system, you get the same behavior. The step form is preferred in practice because it is more readable and less error prone to type.

When a 5-Minute Schedule Makes Sense

Health checks and uptime monitoring

Pinging an endpoint every 5 minutes catches failures within a 5 minute window. Shorter intervals (1 to 2 minutes) are better for critical services, but 5 minutes is a reasonable default for noncritical internal tools.

Cache warming and refresh

If your application caches data that expires after 10 to 30 minutes, a 5 minute cron that prefetches and populates the cache prevents cache misses from hitting downstream services.

Polling external APIs

When a webhook is not available and you need to pull data from an external source, 5 minutes is often the shortest interval that stays within rate limits. Always check the API’s rate limit documentation before setting the interval.

Log rotation or metric aggregation

Some lightweight aggregation tasks (rolling up counters, flushing buffered data) run on short intervals where a 5 minute window is a natural bucket size.

Not a good fit for: anything that needs subminute precision. Cron resolution is 1 minute. For subminute jobs, use a long running process with an internal sleep loop, a systemd timer with OnCalendar=*:0/1, or a job scheduler like Celery Beat.

Alternatives and Comparison

If you are choosing between */5 and */10, ask whether catching an issue 5 minutes earlier justifies running twice as often. For most background jobs, */10 or */15 is sufficient and reduces unnecessary load.

Cron vs systemd Timers

On modern Linux systems with systemd, you can use OnCalendar in a .timer unit instead of cron:

[Timer]
OnCalendar=*:0/5
Persistent=true

OnCalendar=*:0/5 fires at every 5th minute of every hour. The Persistent=true option reruns the job if the system was off when it was scheduled to fire. Standard cron does not do this by default.

Systemd timers also log output to the journal, making journalctl -u yourjob.timer more useful than hunting through /var/log/syslog. For new systems, timers are worth considering. For existing crontab heavy infrastructure, the step syntax is battle tested and widely understood.

Verifying Your Schedule

To check when */5 * * * * will next fire, use a cron parsing tool or run this in Python:

from croniter import croniter
from datetime import datetime

cron = croniter("*/5 * * * *", datetime.now())
for _ in range(5):
    print(cron.get_next(datetime))

Or on the command line with the crontab entry active, check /var/log/syslog or journalctl after the job runs to confirm it executed at the expected times.