* * * * * runs the job every minute, around the clock, on every day of the year. All five fields are stars, which cron reads as “every value”. That adds up to 1,440 runs per day, so check first that your job reliably finishes in well under a minute.
How often does * * * * * actually run?
Sixty times an hour, 1,440 times a day. One minute is also the finest resolution classic cron offers: there is no seconds field, so anything faster needs a systemd timer, a supervised daemon or a sleep loop inside your script. The first run happens at the next full minute after you save the crontab.
What happens if a run takes longer than a minute?
Cron does not wait. The next run starts on schedule even while the previous one is still working, so a script that needs two minutes ends up with two copies running permanently. On a busy server that grows into a pile of stuck processes within hours. The usual guard is a lock: start the command with flock -n on a lock file, and the second start exits immediately.
When is a per-minute schedule the right choice?
Rarely. It fits short local checks: draining a queue, writing a heartbeat, watching a file for changes. Anything that calls a third-party API belongs on a longer interval, because 1,440 requests a day run into rate limits fast. And if what you really mean is “react as soon as possible”, a long-running worker with a queue beats any cron schedule.
How to add the expression
- Open your crontab with crontab -e (the file belongs to the user whose rights the job needs).
- Add the line * * * * * /pfad/zum/skript.sh and save it.
- Wrap the command in flock -n /tmp/meinjob.lock so a slow run cannot overlap the next one.
- Watch the first few runs in the log before you leave the job alone.