Developer guide
Cron Every 10/30/45 Seconds: Sub-Minute Scheduling & Its Limits
“Every 30 seconds” sounds like a cron job, but the standard 5-field crontabcannot go below one minute. The expression */10 * * * * means every10 minutes, not every 10 seconds. This guide covers why that limit exists and every practical way to schedule a real sub-minute interval.
Written by Benjamin Rotshtein
Updated
Can standard cron run a job every 10 or 30 seconds?
No — standard 5-field cron stops at one run per minute, and */10 in the minute field means "every 10 minutes", not 10 seconds. For a true 10/30/45-second cadence you need a sleep loop, 6-field (Vixie) cron, or a scheduler with native sub-minute support such as systemd, n8n, Spring or node-cron.
- Can standard cron do 30 seconds?
- No. Minimum resolution is one minute. Any “seconds” expression needs a 6-field format or a dedicated scheduler.
- Does */30 * * * * mean every 30 seconds?
- No — it means every 30 minutes (at :00 and :30). Seconds require a leading field:
*/30 * * * * *. - Most portable sub-minute option?
- A sleep loop started once by cron, or a systemd timer with
OnCalendar=*:*:0/30.
The one-minute limit
The crontab line has five fields: minute, hour, day-of-month, month, day-of-week. The smallest unit is the minute, and the second field simply does not exist. So the fastest a standard cron job can run is * * * * * — once per minute, 1,440 times a day. There is no expression that means “every 10 seconds” in five fields. The step notation only narrows a field you already have:
*/10 * * * * # every 10 MINUTES (:00 :10 :20 :30 :40 :50) */30 * * * * # every 30 MINUTES (:00 and :30) * * * * * # fastest standard cron: every minute
That is why most “cron every 10 seconds” searches return the wrong answer: the minute-field step is easily mistaken for a seconds interval. If your tool accepts only 5 fields, it cannot run sub-minute jobs, period.
Option 1: a sleep loop started by cron
The classic workaround keeps a single process alive and loops. Cron fires it once at boot or on a coarse schedule; the script then runs the task, sleeps, and repeats forever. It is portable to any Unix cron because cron only sees one 5-field line.
#!/bin/bash # /opt/scripts/every-10s.sh while true; do /opt/scripts/do-work.sh sleep 10 done # crontab line — starts the loop at boot, then it runs itself @reboot /opt/scripts/every-10s.sh
Two caveats: the loop must be crash-safe (restart it from cron if the process dies), and if a single iteration takes longer than the interval, runs start stacking. Add a lock or timestamp check when the task is slow.
Option 2: the 6-field format (Quartz, Spring, n8n, node-cron)
Several schedulers extend cron with a leading seconds field: second minute hour day-of-month month day-of-week. Standard Linux cron rejects these lines, but the schedulers that support them handle seconds natively.
Spring Boot’s @Scheduled is the classic case:
@Scheduled(cron = "0 */30 * * * * *") // every 30 seconds, on second 0 @Scheduled(cron = "*/10 * * * * *") // every 10 seconds @Scheduled(cron = "0 */45 * * * * *") // every 45 seconds
The same 6-field syntax is accepted by Quartz, by node-cron, by n8n’s Cron trigger, and by the extended (Vixie-style) cron formats — it just is not valid in a standard crontab.
Option 3: systemd timers with seconds
systemd timers do not have cron’s minute floor. An OnCalendar expression can include a seconds component, which makes a sub-minute cadence declarative:
# mytimer.timer [Timer] OnBootSec=10s OnCalendar=*:*:0/10 # every 10 seconds, aligned to second 0 AccuracySec=1s # don't drift past the target time Unit=myjob.service
Keep AccuracySec small or systemd may coalesce runs and effectively slow the schedule. For the full comparison with cron, see the systemd timers guide.
When 30 or 45 seconds is really what you need
Before building a sub-minute loop, double-check the intent. Health checks and metrics often genuinely need 10–30 seconds. But many “every 30 seconds” requirements are actually satisfied by every 30 minutes — or by the minute-field expression */30 * * * *. High-frequency cron jobs burn CPU, fill logs, hammer databases and overlap runs. Prefer the slowest cadence that still meets the requirement, and always add overlap protection when the task is slower than the interval.
Frequently asked questions
Can standard cron run a job every 10 seconds?
No. The 5-field crontab format has a minimum resolution of one minute — the seconds field simply does not exist. Writing */10 * * * * runs a job every 10 minutes, not every 10 seconds. For a true 10-second cadence you need a 6-field implementation, a sleep loop, or a dedicated scheduler like node-cron or n8n.
Does */10 * * * * run every 10 seconds?
No — it runs every 10 minutes. The step applies to the minute field, so cron fires at :00, :10, :20, :30, :40 and :50 of each hour. To get seconds you need the leading-seconds (6-field) format, e.g. */10 * * * * *, which is not understood by standard Vixie cron.
How do I run a job every 30 seconds on a normal Linux server?
Standard cron cannot do it. The most portable workaround is a long-running sleep loop started once by cron: a script that runs the task, then sleep 30 and loops forever. Alternatively use a 6-field cron daemon, a systemd timer with OnCalendar=*:*:0/30, or a scheduler such as node-cron or n8n that supports seconds.
What is the 6-field cron format and who supports it?
It prepends a seconds field: second minute hour day-of-month month day-of-week. So 0 */30 * * * * * runs every 30 seconds and */15 * * * * * every 15 seconds. It works in Spring @Scheduled, Quartz, n8n, and libraries like cron-parser and croniter — but standard Vixie cron and most Linux crontabs reject it.
How do I schedule a Spring Boot job every 30 seconds?
Use the 6-field expression with seconds first: @Scheduled(cron = "0 */30 * * * * *") runs every 30 seconds (the leading 0 aligns the fire to second 0). In Quartz the same expression works; remember the extra field exists precisely because the 5-field form bottoms out at one minute.
How do I run a job every 10 seconds with systemd or node-cron?
In a systemd timer use OnCalendar=*:*:0/10 (every 10 seconds) with a short delay after boot. With node-cron use a seconds expression: cron.schedule('*/10 * * * * *', fn) — node-cron accepts the 6-field format and fires the callback every 10 seconds as long as the process stays alive.
Related guides
Build a schedule that survives
Generate the crontab line from plain English — the Cron Generator produces the correct 5-field string and previews the next 5 runs, so “every 30 minutes” is never mistaken for a 30-second interval.