Cron Every Second: Why It Does Not Exist and What to Do

Cron has no seconds field. See why an every-second cron job is impossible, the loop workaround, and the daemon approach you should use instead.

Cron Expression

* * * * *

This is cron's fastest possible schedule — once per minute. A true once-per-second cadence needs the loop workaround or a daemon, explained 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

Let’s be direct: you cannot run a cron job every second. The crontab format has exactly five fields — minute, hour, day of month, month, day of week — and no seconds field. * * * * *, shown above, is the fastest schedule cron can express: once per minute. (Quartz-style schedulers used by Java apps accept a sixth seconds field, e.g. * * * * * ?, but that syntax is rejected by Linux cron.)

If you genuinely need once-per-second execution, here are your options, from quick hack to correct design.

Workaround: Every-Minute Entry + Tight Loop

Cron launches a wrapper each minute; the wrapper runs your job 60 times:

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

With every-1s.sh:

#!/bin/bash
# 60 runs, one per second, for the whole minute
for i in $(seq 0 59); do
  /path/to/your/job.sh &
  sleep 1
done

Be aware of what this really does: 60 process forks a minute, 86,400 a day, with sleep-based timing that drifts slightly because each loop iteration takes nonzero time. It works for light tasks; it is not a precision scheduler.

The Right Tool: a Long-Running Process

At one-second granularity you’ve left cron’s problem domain entirely. Run a small daemon instead:

#!/bin/bash
while true; do
  do_the_work
  sleep 1
done

Supervise it with a systemd service (Restart=always) so it survives crashes and reboots. Alternatively, a systemd timer with OnUnitActiveSec=1 and AccuracySec=100ms works, but at this frequency the service-restart overhead makes the plain daemon loop the cleaner choice.

Why This Is Usually a Design Smell

Wanting cron to fire every second almost always means one of these is true: you’re polling for events (use a queue, inotify, or database notifications instead), you’re building a heartbeat (use systemd watchdogs), or you’re scheduling application work (use your framework’s in-process scheduler). Fixing the architecture beats brute-forcing the schedule.

How to Use

  1. If you just need “as often as cron allows,” use * * * * * via crontab -e
  2. For a true 1-second cadence, deploy the daemon pattern above as a systemd service
  3. Add flock or a PID check if overlapping runs would corrupt state

Related Cron Examples