How to Run a Cron Job Every 10 Seconds in Linux

How to Run a Cron Job Every 10 Seconds in Linux

The standard Linux system scheduler, cron, is designed with a minimum time resolution of 1 minute. The default crontab syntax accepts five time parameters (minute, hour, day of month, month, day of week), offering no native support for seconds or sub-minute intervals.

For operations that require high-frequency execution (such as polling task queues, clearing caches, or querying API endpoints), SRE teams must implement workarounds to bypass the 1-minute crontab limitation.

If you are asking: How do I run a cron job every 10 seconds? This guide covers bash sleep loops, crontab slicing, and setting up native Systemd timers.

1. Method 1: The Bash Sleep Loop (Fastest Implementation)

The most direct way to execute a command every 10 seconds is to write a bash script containing a continuous loop and run it in the background.

Create a file named runner.sh:

#!/bin/bash

# Continuous execution loop
while true; do
    /usr/bin/php /var/www/app/artisan queue:work --once
    sleep 10
done

Run the script in the background using nohup (No Hang Up) so it persists after you disconnect from your SSH session:

nohup /bin/bash /path/to/runner.sh > /var/log/myjob.log 2>&1 &

2. Method 2: The Crontab Splitter Trick

If you must manage the scheduling through your user crontab (crontab -e), trigger a script every minute and use a loop to execute the target command six times, separated by 10-second delays.

First, add this entry to your crontab:

* * * * * /bin/bash /path/to/scheduler-helper.sh

Next, write the scheduler-helper.sh script:

#!/bin/bash

for i in {1..6}; do
    /usr/bin/python3 /path/to/script.py &
    sleep 10
done

The Inherent Drift Limitation

A critical limitation of this method is execution drift. The loop assumes the target process executes instantaneously. If your script takes 2 seconds to run, the actual interval increases:

[\text{Actual Interval} = \text{Sleep Duration} + \text{Task Execution Time}]

In this scenario, a 10-second sleep plus a 2-second runtime results in a 12-second interval, meaning only 5 cycles will fit within the minute. To prevent this, run the command in the background (using &) so the loop sleeps immediately without waiting for the task to finish.

3. Method 3: Systemd Timers (Production Best Practice)

For enterprise environments, SRE teams use Systemd Timers instead of cron. Systemd handles process lifecycle logging, auto-restarts upon crashes, and enables sub-second precision.

Step 1: Create the Systemd Service

Create the service description file at /etc/systemd/system/highfreq-task.service:

[Unit]
Description=High Frequency Task Runner
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/node /var/www/app/worker.js
Restart=on-failure
User=www-data

Step 2: Create the Systemd Timer

Create the timer configuration file at /etc/systemd/system/highfreq-task.timer:

[Unit]
Description=Trigger High Frequency Task Every 10 Seconds

[Timer]
OnBootSec=10s
OnUnitActiveSec=10s
AccuracySec=100ms

[Install]
WantedBy=timers.target

• OnUnitActiveSec=10s: Triggers the service 10 seconds after the last activation ended.
• AccuracySec=100ms: Forces systemd to respect the timer precision (the default is 1 minute to save CPU cycles).

Step 3: Enable the Timer

Enable and start the timer service:

sudo systemctl daemon-reload
sudo systemctl enable --now highfreq-task.timer

4. Comparing Sub-Minute Execution Methods

5. Monitoring High-Frequency Outages with Pingzo

High-frequency background processes are prone to silent failures. If a process encounters a database lock, subsequent runs will back up, consuming server RAM and crashing the server.

Pingzo's heartbeat monitors are designed to audit these workloads:

• Heartbeat Pings: Configure your script or systemd timer to ping a Pingzo webhook URL.
• Silence Thresholds: Set an alarm window. If Pingzo does not receive a ping within your target threshold, it registers a service failure.
• WhatsApp Alert Routing: Receive instant WhatsApp notifications when your background worker crashes, preventing backend queue stagnation.