Cron Every 5 Seconds: What Works and What to Use Instead

No cron expression runs every 5 seconds. Learn the sleep-loop crontab pattern, systemd OnUnitActiveSec timers, and when to use a daemon instead.

Cron Expression

* * * * *

Standard cron's smallest interval is one minute. This entry runs a wrapper every minute; the wrapper loops with sleep to hit a 5-second cadence (12 runs per minute) — see below.

Expression Breakdown

*
Minute
(0-59)
*
Hour
(0-23)
*
Day
(1-31)
*
Month
(1-12)
*
Weekday
(0-6)
Field Value Meaning
Minute * Any minute
Hour * Any hour
Day of Month * Any day
Month * Any month
Day of Week * Any day of the week

Cron cannot schedule anything every 5 seconds. The classic 5-field crontab format has no seconds field at all — the finest granularity is * * * * *, once per minute. So the honest answer has two parts: a workaround built on cron, and a better tool for the job.

Workaround 1: Every-Minute Entry + Sleep Loop

Launch a wrapper each minute that runs your job 12 times, 5 seconds apart:

* * * * * /path/to/every-5s.sh

With every-5s.sh:

#!/bin/bash
# 12 runs per minute: :00, :05, :10 ... :55
for i in $(seq 0 11); do
  /path/to/your/job.sh &
  sleep 5
done

Backgrounding with & keeps the schedule steady even when a run is slow. Note the last iteration starts at second :55, so the loop finishes just as cron launches the next wrapper — the cycle hands off cleanly.

Workaround 2: systemd Timer

For anything long-lived, a systemd timer is sturdier than cron-plus-sleep:

[Timer]
OnBootSec=5
OnUnitActiveSec=5
AccuracySec=100ms

OnUnitActiveSec=5 re-triggers the service 5 seconds after each activation, and tightening AccuracySec stops systemd from batching timers into its default 1-minute window.

Honestly: Consider a Daemon

At a 5-second cadence you’re spawning 17,000+ processes a day. That’s usually a sign the task wants to be a long-running process — a small daemon with while true; do work; sleep 5; done under systemd supervision, a queue consumer, or an async job scheduler inside your application (Celery beat, Sidekiq, node-cron with seconds support). You get overlap control, state between runs, and far less fork overhead.

How to Use

  1. Add the every-minute expression above with crontab -e
  2. Save the loop script and chmod +x it
  3. Guard against overlap with flock -n /tmp/job.lock inside the loop if needed
  4. Reassess after prototyping — promote the job to a systemd service if it sticks around