Cron: every minute
Five asterisks match every value of every field, so the job starts at the beginning of each minute. It is the most frequent schedule standard cron can express, and the one most likely to start a second copy before the first has finished.
Expression
* * * * * At every minute, all day, every day
Next 5 runs
The same schedule on other platforms
| Platform | Written as | Note |
|---|---|---|
| Linux crontab | * * * * * | Five fields, in the server's local time zone. A % in the command has to be escaped as \%. |
| GitHub Actions | - cron: '* * * * *' | Accepted, but GitHub runs scheduled workflows at most every 5 minutes. |
| Kubernetes CronJob | schedule: "* * * * *" | Five fields, in the controller's time zone unless spec.timeZone is set (Kubernetes 1.27 and later). concurrencyPolicy decides what happens when runs overlap. |
| systemd timer | OnCalendar=minutely | Its own calendar syntax, in a .timer unit, local time. hourly, daily and monthly match cron, but weekly means Monday. Persistent=true catches up on runs missed while the machine was off. |
| AWS EventBridge | cron(* * * * ? *) | Or rate(1 minute), which counts from when the rule was created instead of the top of the minute. |
| Quartz / Spring | 0 * * * * ? | Six fields, seconds first. Quartz needs ? in one of the day fields and counts Sunday as 1; Spring accepts ? and numbers days like cron. |
Common mistakes
Runs pile up
Cron doesn't wait for the previous run. A job that sometimes takes 90 seconds ends up running twice at once. Wrap it in
flock -n /tmp/job.lock job.sh, or setconcurrencyPolicy: Forbidon a Kubernetes CronJob.There is no seconds field
Standard cron can't go below a minute. For every 30 seconds, add a second line that waits first:
* * * * * sleep 30; job.sh. Quartz can, because its first field is seconds.Not every minute on GitHub
* * * * *is accepted in a workflow file, but GitHub starts scheduled workflows at most every 5 minutes, and often later than that.