Crontab Every 5 Minutes, Every 15 Minutes and Every 4 Hours (plus systemd Timers)

A crontab line has five time fields (minute, hour, day of month, month, day of week) followed by the command. An asterisk means every value, and */n means every n-th value starting from the lowest.

A step value counts from the start of the range, not from when you saved the crontab. */5 runs at :00, :05 and :10, even if you added the line at 09:03.

Use */5 * * * *. It runs at minute 0, 5, 10 and so on through 55, which is 12 times per hour and 288 times per day.

*/5 * * * * /usr/local/bin/healthcheck.sh >> /var/log/healthcheck.log 2>&1

Always use absolute paths and redirect output. Cron runs with a minimal PATH and mails any output to the local user, which most servers never read.

See the cron every 5 minutes and crontab every 5 minutes presets for the next run times in UTC and your local zone.

Use */15 * * * *. It runs at :00, :15, :30 and :45 every hour, which is 96 runs per day.

0,15,30,45 * * * * is the same schedule written as a list. Some teams prefer the list because it is easier to read in a code review.

If many servers run the same job, shift the start minute to spread the load. 7-59/15 * * * * runs at :07, :22, :37 and :52. The cron every 15 minutes preset shows both forms.

Use 0 */4 * * *. It runs at minute 0 of hours 0, 4, 8, 12, 16 and 20, which is 6 runs per day.

The minute field matters here. * */4 * * * looks similar but runs every minute during those hours: 60 runs at 00:00–00:59, then 60 more at 04:00. That is 360 runs per day instead of 6.

0 */4 * * *    /usr/local/bin/rotate-keys.sh
0 2-23/4 * * * /usr/local/bin/rotate-keys.sh   # 02:00, 06:00, 10:00 …

Open the cron every 4 hours preset to confirm the schedule before you deploy it.

Use 0 * * * * or the @hourly shortcut. Both run once at minute 0 of every hour, 24 times per day.

People often search "every hours" when they mean this schedule. Writing * * * * * by mistake runs the job every minute instead, so check the first field twice.

The crontab every hour preset lists the next runs and the matching systemd timer.

runs per day = (values matched in minute field) × (values matched in hour field) e.g. */15 → 4 × 24 = 96

Put an OnCalendar= expression in a .timer unit that starts a matching .service unit. *:0/5 is every 5 minutes, *:0/15 every 15 minutes, hourly every hour and 0/4:00 every 4 hours.

# backup.service
[Unit]
Description=Backup job

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

# backup.timer
[Unit]
Description=Run backup every 4 hours

[Timer]
OnCalendar=0/4:00
Persistent=true
RandomizedDelaySec=5min

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer
systemd-analyze calendar '0/4:00'
systemctl list-timers backup.timer
journalctl -u backup.service --since today

Persistent=true runs a missed job after the machine boots, which cron does not do. RandomizedDelaySec spreads load across a fleet. The Cron Visualizer generates both unit files from any cron line.

Use cron for simple per-user jobs and portability. Use systemd timers when you need logging, catch-up after downtime, resource limits or dependencies.

The usual causes are a missing PATH, an unescaped % sign, the wrong time zone, or a previous run that is still going.

• PATH: cron uses a short default PATH. Call binaries by absolute path or set PATH= at the top of the crontab.
• Percent signs: cron turns % into a newline. Escape it as \%, for example in date +\%F.
• Time zone: cron uses the system time zone. Check it with timedatectl before you schedule jobs for a specific hour.
• Overlap: wrap long jobs in flock -n /tmp/job.lock so a slow run does not stack up behind the next one.

grep CRON /var/log/syslog | tail -20     # Debian / Ubuntu
journalctl -u cron --since "1 hour ago"   # systemd hosts (crond on RHEL)

If a crontab entry runs an encoded command you did not write, treat it as persistence. Decode it with the Log De-obfuscator and hunt for the same pattern across hosts with the KQL & SPL builder.

User crontabs live in /var/spool/cron and are edited with crontab -e. System jobs live in /etc/crontab and /etc/cron.d, where each line has an extra user field.

The user field is the detail that breaks copied lines. A line from a personal crontab pasted into /etc/cron.d reads the first word of the command as a user name and fails.

During an investigation, list every location rather than only crontab -l. Attackers like /etc/cron.d because few people look there. ls -la /etc/cron.* /var/spool/cron/* shows each file with its owner and change time.

Preview the next run times in a cron translator, run the command once by hand as the cron user, and check the log after the first scheduled run.

1. Paste the expression into the Cron Visualizer and confirm the next five run times.
2. Run the exact command with sudo -u <user> env -i /bin/sh -c '<command>' to copy cron's empty environment.
3. Check the syslog or journal after the first run, and confirm the output file was written.

These three checks catch most failures before they reach production. They take less than a minute and save hours of wondering why a backup never ran.