Cron Expression for Every Minute: * * * * *

The * * * * * Expression

The cron expression * * * * * fires at every minute mark: 00:00, 00:01, 00:02, and so on, totaling 60 times per hour, 1440 times per day. A bare * in any cron field means “every valid value in this field.” With all five fields set to *, there is no filter: the job runs on every possible schedule boundary.

This is the maximum frequency cron supports. The minute field is the finest granularity cron has, so * * * * * is as fast as cron gets.

When Per-Minute Makes Sense

Queue workers with a cron based trigger

Some systems use cron to kick off a worker that drains a job queue. If jobs arrive continuously and latency matters, a per minute trigger ensures the queue does not sit idle for long. That said, a proper message queue with a long polling consumer is a cleaner architecture for this pattern.

Real time monitoring on systems without a dedicated agent

If you cannot install a persistent monitoring agent, a per minute cron that checks a health endpoint or logs a metric is a pragmatic fallback. It will not catch failures that occur and recover within 60 seconds, but it is better than polling every 5 minutes for a critical service.

Lightweight heartbeat signals

Writing a timestamp to a file or database every minute is a common liveness check. Some dead man’s switch implementations depend on this. If the heartbeat stops updating, an alert fires.

When It Is Overkill

Anything with a natural batch boundary

If you are generating reports, syncing data, or sending notifications, ask whether users actually need updates every minute. Most “near real time” requirements are satisfied by a 5 minute interval. Per minute cron is often chosen by default and never revisited.

Jobs with meaningful startup cost

If your job connects to a database, loads configuration from a remote source, or authenticates against an external API, it pays that cost 1440 times a day. A long running daemon pays it once.

Jobs that sometimes take longer than 60 seconds

Standard cron does not know whether the previous run is still executing. If the job takes 90 seconds, you will have two instances running simultaneously at minute 2. This leads to race conditions, duplicate work, and resource contention.

Preventing Concurrent Execution

For any per minute cron job, test what happens when execution time exceeds 60 seconds. The standard fix is flock:

* * * * * flock -n /tmp/myjob.lock /path/to/myjob.sh

flock -n acquires an exclusive lock on the file. If a previous invocation still holds the lock, the new one exits immediately. This prevents overlap without killing the running job.

Alternatively, use a PID file check in your script, or a dedicated tool like run-one on Debian based systems:

* * * * * run-one /path/to/myjob.sh

Subminute Alternatives

If one minute is too slow, these are the real options:

systemd timer with a sleep loop

Create a .service unit that loops internally and a .timer unit that starts it on boot. The service runs while true; do /path/to/task; sleep 10; done. You get subminute execution with proper restart behavior and journal logging.

Sleep based double entry (30-second workaround)

Two crontab lines:

* * * * * /path/to/job
* * * * * sleep 30 && /path/to/job

This approximates a 30 second interval. It is fragile under load but works for low stakes tasks.

Celery Beat / APScheduler / similar

Application level schedulers run inside your process and support arbitrary intervals including subsecond. If you are already running a Python or Node.js service, these are preferable to cron for high frequency tasks.

Kubernetes CronJobs

Kubernetes CronJobs have the same 1 minute minimum as system cron. For subminute workloads in Kubernetes, use a Deployment with a loop in the container, not a CronJob.

Verifying Execution

With * * * * * active, you should see 60 log entries per hour. Verify on Linux:

grep CRON /var/log/syslog | grep myjob | tail -5

Or with systemd:

journalctl -u cron --since "1 hour ago" | grep myjob

If you see gaps in the per minute cadence, investigate: load average, disk I/O wait, or a lock contention issue from overlapping runs.