Can Cron Run Every 30 Seconds?
Standard cron can't run a job every 30 seconds: its smallest unit is the minute, so the most often a cron expression can fire is once a minute, with * * * * *. To run something every 30 seconds you need a workaround — two cron lines with a sleep, or a systemd timer.
Standard cron can't run more often than once a minute — its smallest field is the minute, so a schedule in seconds can't be written. Run a one-minute job that repeats its work after a sleep, or use a systemd timer.
— — — — —This isn't a mistake in what you typed — standard cron has no way to write this schedule. See the workarounds.
Fix the expression to see run times.
Why standard cron can't do this
A cron expression has five fields — minute, hour, day of month, month and day of week — and none of them measures seconds. Cron wakes up once a minute, checks every crontab for lines whose fields match the current minute, and starts those jobs. There's nothing to match at 30 seconds past, so no expression can mean “every 30 seconds”.
Seconds aren't just missing from the syntax; they're missing from how the daemon works. Classic cron sleeps until the start of the next minute, looks for matching jobs, runs them, and goes back to sleep. That design keeps it simple and cheap, and it's why cron jobs always start at around second 0.
The six-field expressions you may have seen, such as */30 * * * * *, come from other schedulers: Quartz, Spring's @Scheduled and some Node.js libraries add a leading seconds field. In a system crontab, a sixth field isn't even a syntax error — cron reads the first five fields as the schedule and treats the rest of the line as the command, so */30 * * * * * /path/to/job runs every 30 minutes and hands the shell a stray *.
Before reaching for a workaround, check whether 30 seconds is really the requirement. A job that polls for new work is often better as a long-running worker that waits on a queue, or as something triggered by a webhook, than as a task a scheduler fires twice a minute. If it genuinely has to be time-based, the options below are reliable.
Workarounds that do work
Two cron lines, one delayed by 30 seconds
Run the job every minute, and again every minute after a 30-second sleep. It works with any cron, but the two runs overlap if the job ever takes longer than 30 seconds, so guard it with flock, which makes a second copy exit while the first still holds the lock.
* * * * * flock -n /tmp/poll.lock /usr/local/bin/poll.sh
* * * * * sleep 30; flock -n /tmp/poll.lock /usr/local/bin/poll.shA systemd timer
On Linux with systemd, a timer can fire on any second. OnCalendar=*:*:0/30 means every 30 seconds, and AccuracySec=1s matters: without it systemd may batch timer events within a one-minute window. systemd also won't start a second copy of the service while the previous run is still active.
# /etc/systemd/system/poll.service
[Unit]
Description=Poll the queue
[Service]
Type=oneshot
ExecStart=/usr/local/bin/poll.sh
# /etc/systemd/system/poll.timer
[Unit]
Description=Run poll.service every 30 seconds
[Timer]
OnCalendar=*:*:0/30
AccuracySec=1s
[Install]
WantedBy=timers.target
# then: systemctl daemon-reload && systemctl enable --now poll.timerA loop in a long-running process
If the work lives in a service anyway, let it loop: do the work, sleep for 30 seconds, repeat. Run it under systemd or your container platform so it restarts if it crashes. The interval stretches by however long each pass takes.
#!/bin/sh
while true; do
/usr/local/bin/poll.sh
sleep 30
doneFrequently asked questions
What is the smallest interval cron can run?
One minute. * * * * * runs a job every minute, and nothing in standard cron syntax can go below that.
Why does */30 * * * * * run every 30 minutes instead of every 30 seconds?
Because standard cron has only five time fields. It reads */30 * * * * as the schedule — every 30 minutes — and treats the sixth * as the start of the command.
Do Kubernetes CronJobs support seconds?
No. Kubernetes CronJobs use the standard five-field syntax, so their smallest interval is also one minute. For sub-minute work, run a Deployment that loops or consumes from a queue.