In this lesson, you will learn why the standard Linux cron daemon is fundamentally incapable of scheduling tasks at intervals shorter than one minute.
The One-Minute Barrier
At its core, cron is a periodic task manager that operates on a resolution of exactly 60 seconds. When you examine the traditional crontab format—* * * * *—each field represents Minute, Hour, Day, Month, and Day of Week. Because the smallest unit of time that the cron daemon evaluates is the minute, you cannot define a schedule like "every 30 seconds."
The limitation is baked into the architecture of the cron daemon. The process wakes up at the beginning of every minute, scans all user and system crontabs, triggers the jobs due for that specific minute, and then puts itself to sleep for the remainder of the cycle. It lacks the internal mechanism to "wait" for partial minute offsets, meaning any task meant to run at a sub-minute frequency simply cannot be registered.
The Workaround Trap
You might be tempted to circumvent this with a script using sleep commands, such as:
* * * * * /usr/local/bin/myscript.sh
* * * * * sleep 30; /usr/local/bin/myscript.sh
While this appears to achieve 30-second granularity, it introduces significant instability. If myscript.sh takes more than a few seconds to run, or if the system experiences slight latency in task initiation, the execution start times will "drift." Furthermore, you are relying on the process scheduler to wake your script precisely on time, which is not guaranteed.
Because cron is designed for system administrative tasks—like rotating logs or cleaning temporary files—this one-minute floor is usually sufficient. However, for high-frequency requirements like polling a network interface or monitoring microservice state changes, cron is the wrong tool. Attempting to force sub-minute execution via cron leads to race conditions, overlapping processes, and unpredictable performance bottlenecks. If your automation requires high-frequency execution, you must look toward persistent daemons or systemd timers with high-resolution precision.
Key Takeaway: The cron daemon is architecturally bound to a 60-second resolution, making it unsuitable for high-frequency tasks where sub-minute precision is required.