How to Run a Cron Job Every Minute

By CronHub Tools · Updated 2026-08-14

To run a cron job every minute, place an asterisk in all five schedule fields. Use absolute paths because cron provides a minimal environment, and redirect output so failures do not disappear. For a production job, add flock so a slow run cannot overlap the next one.

* * * * * /usr/local/bin/task >> /home/alice/logs/task.log 2>&1

The every-minute cron expression

A standard Linux crontab uses five schedule fields followed by the command:

* * * * * /usr/local/bin/task

Each asterisk means “every allowed value” for that field.

The daemon evaluates this schedule at minute boundaries. It can start the command at 10:00, 10:01, 10:02, and so on, but cron itself does not provide a seconds field in the usual five-field format.

You can build and preview this schedule once on cronhub.online if you want to confirm the next run times before editing your crontab.

Add the job to your crontab

First create a directory for the log file:

/usr/bin/mkdir -p /home/alice/logs

Open your user crontab:

/usr/bin/crontab -e

Add the schedule and command:

* * * * * /usr/local/bin/task >> /home/alice/logs/task.log 2>&1

Save the file and exit the editor. You can verify the installed entry with:

/usr/bin/crontab -l

Replace /home/alice with your actual home directory and /usr/local/bin/task with the full path to your executable or script.

The redirection appends standard output to the log file. The 2>&1 portion sends standard error to the same destination, which gives you one place to inspect normal output and failures.

When running every minute is appropriate

A per-minute schedule works well when you need frequent polling but do not require second-level precision. Common examples include:

• Draining a small application queue.
• Importing newly arrived files.
• Sending batches of pending notifications.
• Refreshing a cache from a local data source.
• Checking whether a service-specific condition has changed.
• Processing database rows marked as ready.
• Running a lightweight reconciliation task.

The job should usually be quick, repeatable, and safe to retry. If running the same operation twice could duplicate payments, messages, or records, the application should enforce idempotency in addition to using a process lock.

A per-minute cron job is a poor fit when the task must react immediately, maintain a persistent connection, or run continuously. A worker service, queue consumer, or systemd service is usually more suitable in those cases.

It is also worth reconsidering the interval if the work rarely changes. Running every five minutes may reduce unnecessary database queries, API calls, log volume, and lock contention without materially delaying the result.

Why overlapping runs are the real risk

Cron starts jobs according to the schedule; it does not normally wait for the previous invocation to finish. If your task occasionally takes longer than one minute, a second copy can start while the first is still running.

Overlap can cause duplicated work, conflicting file writes, database lock contention, excessive CPU or memory use, and requests that pile up faster than they complete. A temporary slowdown can therefore turn into a growing backlog of concurrent processes.

Do not assume that a job normally finishing in ten seconds makes overlap impossible. Network timeouts, unavailable databases, locked files, large input batches, or a stalled subprocess can make one invocation run far longer than usual.

You can reduce the risk by setting timeouts inside the application, making operations idempotent, and allowing only one invocation at a time.

Prevent overlap with flock

On Linux, flock can acquire an advisory lock before starting the command. The following setup creates a private directory for the lock file and the log:

/usr/bin/mkdir -p /home/alice/.local/state/cron-locks
/usr/bin/mkdir -p /home/alice/logs
/usr/bin/chmod 700 /home/alice/.local/state/cron-locks

Use this crontab entry:

* * * * * /usr/bin/flock -n /home/alice/.local/state/cron-locks/task.lock /usr/local/bin/task >> /home/alice/logs/task.log 2>&1

The options and arguments mean:

• /usr/bin/flock runs the locking utility by absolute path.
• -n requests nonblocking behavior.
• The .lock path identifies this particular job.
• /usr/local/bin/task runs only after the lock is acquired.
• The lock is released automatically when the command exits.

If the previous invocation still holds the lock, the new invocation exits immediately instead of waiting or running concurrently. The lock file may remain on disk after the process exits; its presence alone does not mean the lock is active.

Use a different lock file for each independent job. Reusing one lock file intentionally serializes all commands that use it, which may be useful when several jobs access the same exclusive resource.

Use a wrapper when skipped runs must be logged

A short wrapper script gives you more control over lock conflicts, logging, environment variables, and exit handling. Create /usr/local/bin/run-task-locked with this content:

#!/bin/bash

LOCK_FILE=/home/alice/.local/state/cron-locks/task.lock

exec 9>"$LOCK_FILE"

if ! /usr/bin/flock -n 9; then
    /usr/bin/logger -t task-cron "Skipped run because the previous invocation is still active"
    exit 0
fi

exec /usr/local/bin/task

Make it executable:

/usr/bin/chmod 750 /usr/local/bin/run-task-locked

Schedule the wrapper rather than the application directly:

* * * * * /usr/local/bin/run-task-locked >> /home/alice/logs/task.log 2>&1

This version writes a message to the system log when a run is skipped. It exits successfully on lock contention because the skip is expected behavior. If skipping work should trigger an alert, exit with a nonzero status instead and connect the job to your monitoring system.

Choose whether to skip or wait

Nonblocking mode is generally the safest choice for a frequent polling job. If one run is still active, the next scheduled run is skipped and the following minute provides another opportunity.

Waiting for the lock may be appropriate when every invocation represents distinct work that must eventually run. However, waiting cron processes can accumulate if the task remains slow. A queue is often a better design when every unit of work must be preserved.

You can set a bounded wait with flock:

* * * * * /usr/bin/flock -w 20 /home/alice/.local/state/cron-locks/task.lock /usr/local/bin/task >> /home/alice/logs/task.log 2>&1

This invocation waits up to 20 seconds for the lock. If it cannot acquire the lock within that period, it exits without running the task.

Account for cron’s limited environment

A command that works in your interactive shell may fail under cron because the working directory, PATH, shell configuration, credentials, and environment variables can differ.

Use absolute paths for executables, scripts, configuration files, input files, and output files. If the program expects a specific working directory, change directories explicitly in a wrapper:

#!/bin/bash

cd /srv/example-app || exit 1
exec /usr/bin/python3 /srv/example-app/jobs/process_queue.py

Do not depend on aliases, shell startup files, or an activated Python virtual environment. Call the virtual environment’s interpreter directly when needed:

* * * * * /usr/bin/flock -n /home/alice/.local/state/cron-locks/queue.lock /srv/example-app/.venv/bin/python /srv/example-app/jobs/process_queue.py >> /home/alice/logs/queue.log 2>&1

Keep secrets out of the crontab when possible. Load them from a protected configuration file or a credential mechanism supported by your application.

Test before relying on the schedule

Run the exact command manually under the same user account:

/usr/bin/flock -n /home/alice/.local/state/cron-locks/task.lock /usr/local/bin/task

Check the resulting exit status:

/bin/echo "$?"

You can test contention in one terminal by holding the lock:

/usr/bin/flock /home/alice/.local/state/cron-locks/task.lock /usr/bin/sleep 90

While that process is active, run the nonblocking command in another terminal:

/usr/bin/flock -n /home/alice/.local/state/cron-locks/task.lock /usr/local/bin/task

The second command should exit without starting the task. After installing the crontab, inspect the log:

/usr/bin/tail -n 100 /home/alice/logs/task.log

A lock prevents overlap, but it does not prove that successful work occurred. Monitor exit codes, expected output, last-success timestamps, or application-level results so a repeatedly failing or repeatedly skipped job cannot remain silent.

A local flock lock only coordinates processes that can see and honor the same filesystem lock. If the same cron job runs on multiple servers, use a distributed lock, database constraint, queue, or scheduler designed for multi-host coordination.

Frequently Asked Questions

Related guides

References

• flock manual page — documents nonblocking locks, wait timeouts, file descriptors, and exit behavior
• crontab manual page — defines crontab fields, command execution, environment handling, and time behavior