Every minute cron: what * * * * * means and when it is too often

Reading * * * * * field by field

A standard cron line has five fields in a fixed order: minute, hour, day of month, month and day of week. A bare asterisk means every allowed value of that field, so five asterisks match every minute of every hour of every day. There is no seconds field in classic cron, which makes one minute the shortest interval a crontab can express.

The parser on this page agrees: Every minute. The next run times in the panel above are computed in your browser, in your own timezone, so they are not printed in this text.

A crontab line and the overlap problem

A typical entry looks like * * * * * /usr/local/bin/poll-queue.sh >> /var/log/poll-queue.log 2>&1. Cron starts the command with a minimal environment, usually a short PATH and no shell profile, so use absolute paths and redirect output, otherwise cron tries to mail it to the owner.

The real risk at this frequency is overlap. Cron does not wait for the previous run to finish; if one run takes 70 seconds, two copies are alive at the same time, and a slow day can pile up dozens. Wrap the command in a lock: * * * * * flock -n /run/lock/poll-queue.lock /usr/local/bin/poll-queue.sh makes a second copy exit immediately instead of queueing behind the first.

systemd, Kubernetes and GitHub Actions

The systemd timer equivalent is OnCalendar=minutely (the same as *-*-* *:*:00). Timers never start a second instance of a running service, which removes the overlap problem without flock, and AccuracySec=1s stops systemd from coalescing the start time.

In a Kubernetes CronJob, schedule: "* * * * *" creates a new Job and Pod every minute; set concurrencyPolicy: Forbid so a slow run is skipped rather than doubled, and remember that Pod start-up latency eats into a 60-second budget. GitHub Actions accepts the expression but runs scheduled workflows at most every 5 minutes, and only in UTC.

When every minute is the wrong answer

Every-minute jobs are usually polling something that could push an event instead: a queue, a webhook, a file watcher. If the job only needs to react within a few minutes, every 5 minutes cuts the load fivefold; if it runs continuously anyway, a long-running service with its own loop is easier to monitor than 1,440 short processes a day.