Cron Expression Every Minute: Exact Syntax and Examples

By CronHub Tools · Updated 2026-08-15

The standard five-field cron expression for every minute is * * * * *. Put it before the command you want to run, using absolute paths so the job does not depend on your interactive shell environment.

* * * * * /usr/local/bin/task.sh

This schedule runs once during every clock minute, subject to the cron daemon being active and the previous invocation not blocking or conflicting with the next one.

The exact every-minute cron expression

Use five asterisks for a standard Linux or Unix crontab:

* * * * *

When attached to a command, a complete crontab entry looks like this:

* * * * * /usr/local/bin/task.sh

The five schedule values mean:

The first asterisk is the part that directly produces the every-minute behavior. The remaining asterisks ensure that no hour, date, month, or weekday restricts it.

You may also encounter this equivalent expression:

*/1 * * * *

It means every one minute in cron implementations that support step values. However, * * * * * is shorter, clearer, and the conventional choice. Use the step form when the interval is greater than one, such as an every-five-minutes schedule.

You can build and preview the schedule on cronhub.online if you want to confirm the next expected run times before installing it.

Copy-and-paste crontab examples

Run a shell script every minute

Use the script’s absolute path:

* * * * * /bin/bash /opt/myapp/bin/process-queue.sh

Make sure the cron user can read the script and access every file or directory the script uses. If the script already has a valid shebang and executable permission, you can invoke it directly:

* * * * * /opt/myapp/bin/process-queue.sh

Run a Python script every minute

Specify the Python interpreter rather than assuming cron will find it:

* * * * * /usr/bin/python3 /opt/myapp/scripts/worker.py

If your application uses a virtual environment, call that environment’s interpreter:

* * * * * /opt/myapp/venv/bin/python /opt/myapp/scripts/worker.py

This avoids running the script with a different Python installation or missing the packages installed in your virtual environment.

Call an HTTP endpoint every minute

Use an absolute path to curl, fail on HTTP errors, and set a timeout shorter than the schedule interval:

* * * * * /usr/bin/curl --fail --silent --show-error --max-time 50 https://example.com/internal/cron/run

Do not put credentials directly in a crontab if other users can read it. Prefer a protected configuration file, environment-specific secret store, or another authentication mechanism appropriate for your system.

Save output to a log file

Cron may email captured output when local mail is configured. For an explicit log file, redirect both standard output and standard error:

* * * * * /opt/myapp/bin/process-queue.sh >> /var/log/myapp/process-queue.log 2>&1

The cron user must have permission to create or append to the file. Configure log rotation as well, because a command that writes output every minute can produce an indefinitely growing file.

Discard all output

For a quiet job whose output you intentionally do not need:

* * * * * /opt/myapp/bin/heartbeat.sh > /dev/null 2>&1

Discarding errors makes failures harder to detect. Use this only when the command reports failures through monitoring, an application log, or another reliable channel.

Prevent overlapping every-minute runs

Cron starts a new invocation on each matching minute. It does not wait for the previous invocation to finish. If your command sometimes takes longer than one minute, multiple copies can run simultaneously.

On Linux systems with flock, use a non-blocking lock:

* * * * * /usr/bin/flock -n /run/lock/myapp-worker.lock /opt/myapp/bin/process-queue.sh

The -n option causes the new invocation to exit immediately if another process holds the lock. This is usually preferable to allowing old invocations to queue indefinitely.

If the crontab belongs to an unprivileged user who cannot write under /run/lock, choose a secure directory owned by that user:

* * * * * /usr/bin/flock -n /home/deploy/.local/run/myapp-worker.lock /opt/myapp/bin/process-queue.sh

Create the parent directory first and restrict its permissions:

/usr/bin/mkdir -p /home/deploy/.local/run
/usr/bin/chmod 700 /home/deploy/.local/run

Locking is especially important for queue processors, imports, backups, and scripts that modify shared files or database rows.

Install and verify the expression

Edit the current user’s crontab with:

crontab -e

Add the schedule and command as one line:

* * * * * /opt/myapp/bin/process-queue.sh >> /var/log/myapp/process-queue.log 2>&1

Save the file, then confirm that the entry was installed:

crontab -l

Remember that a user crontab and the system crontab are not identical. Files such as /etc/crontab and entries under /etc/cron.d/ usually include an additional username between the schedule and command:

* * * * * deploy /opt/myapp/bin/process-queue.sh

Do not add that username column when using crontab -e. In a user crontab, adding deploy would make cron try to execute a command named deploy.

Account for cron’s minimal environment

A command that works in your terminal may fail under cron because cron supplies a smaller environment. It may have a different working directory, limited PATH, and none of the variables loaded by your interactive shell.

You can define a predictable shell and path at the top of the crontab:

SHELL=/bin/bash
PATH=/usr/local/bin:/usr/bin:/bin

* * * * * /opt/myapp/bin/process-queue.sh

Absolute paths are still preferable for the executable, scripts, configuration files, and output files. If the application expects a particular working directory, change to it explicitly:

* * * * * cd /opt/myapp && /opt/myapp/bin/process-queue.sh

Cron interprets an unescaped percent sign in a command specially on many traditional implementations. If your command contains date formatting or a URL-encoded value with %, escape it or move the command into a script to avoid surprising input handling.

What every minute actually guarantees

An every-minute expression schedules the command against clock-minute boundaries. It does not mean “wait exactly 60 seconds after the previous run finishes.”

For example, cron may start a job near 12:00, 12:01, and 12:02. System load, daemon scheduling, clock changes, or downtime can delay or prevent an individual invocation. Traditional cron also does not normally replay every missed run after the machine starts again.

The schedule has one-minute granularity. If you need execution every few seconds, a standard five-field crontab is not the right scheduler. Consider a long-running process, an application-level scheduler, or a systemd timer designed for the required timing behavior.

Five-field cron versus expressions with seconds

The five-field expression applies to standard crontab implementations:

* * * * *

Some frameworks and hosted schedulers use six or seven fields. A six-field format may place seconds first, but field order and wildcard rules vary between products. Copying six asterisks without checking the scheduler can accidentally request execution every second.

For a Quartz-style expression that includes seconds, an every-minute schedule commonly uses zero in the seconds field:

0 * * * * ?

Do not use the Quartz expression in a Linux crontab. Confirm the exact format in your scheduler’s documentation before pasting an expression intended for another implementation.

Common mistakes

Using a five-minute step

This expression runs every five minutes, not every minute:

*/5 * * * *

For every minute, use:

* * * * *

Restricting the hour accidentally

This runs every minute only during the 9 a.m. hour:

* 9 * * *

The unrestricted every-minute expression requires an asterisk in the hour field.

Expecting the job to start immediately

Cron evaluates schedules by minute. After you save the crontab, the first run generally occurs at the next matching minute boundary, not necessarily at the instant you save it.

Assuming cron prevents duplicate processes

The expression controls start times only. Use locking or make the task safe to run concurrently if one invocation can still be active when the next minute arrives.

Frequently Asked Questions

Related guides

References

• Linux crontab manual page — documents crontab fields, environment handling, extensions, and command parsing
• POSIX crontab utility specification — defines the portable behavior and interface of the crontab utility
• Cronie project documentation — provides source documentation for a widely used Linux cron implementation