What * * * * * schedules
A cron every minute schedule is the shortest expression in the format and the easiest to misread as harmless. All five fields are stars, so every field matches everything, and the job fires 1,440 times a day, at second zero of each minute, forever. There is no ramp and no back-off. If the first run fails, the second one starts sixty seconds later with exactly the same inputs.
When every minute is the right answer
Three shapes justify it. The first is a watchdog that checks something cheap and local, such as whether a process is alive or a lock file has gone stale, and does nothing 99 per cent of the time. The second is a drain on a queue that already holds work, where the cost of an empty run is one query and the benefit is latency measured in seconds rather than minutes. The third is a heartbeat that some external monitor expects to see.
What these have in common is that the run is cheap when there is nothing to do. That is the test worth applying before you install the line.
When it is a polling loop in disguise
The failure mode is subtler than load. A job that polls an external API every minute burns 43,200 calls a month whether or not anything changed, and it will keep burning them long after the feature that needed it was switched off. If the upstream system can push to you, a webhook removes the schedule entirely. If your work arrives as a queue, a long-lived worker blocks on the queue instead of waking up to ask.
Cron is a clock, not an event loop. Reaching for a one-minute schedule is usually the moment to check whether you actually wanted an event.
Overlap is the failure you will meet
Assume the job will one day take ninety seconds, because eventually it will. Wrap it so a second copy cannot start:
* * * * * /usr/bin/flock -n /tmp/sync.lock /opt/app/sync.sh >> /var/log/sync.log 2>&1
flock -n takes the lock or exits straight away, and the run that would have overlapped simply does
not happen. This one change turns the worst per-minute failure into a skipped tick. Redirecting the
output matters just as much, because without it every run mails its output to a local mailbox nobody
reads, and the disk fills up quietly.
What the logs will look like
At this frequency the log is the first thing to break. A line per run is 1,440 lines a day, and the signal you actually want — the run that failed — sits inside noise generated by the 1,439 that did not. Log the outcome only when it is interesting, keep a counter for the rest, and rotate whatever you do write. A per-minute job with an unrotated log file is a disk alert with a delay on it.
Narrower is usually better
Most jobs installed as * * * * * do not need the night, the weekend, or both. The variants above
restrict the same schedule to office hours and to weekdays, which cuts the run count by roughly
three quarters without changing anything the job does. If a minute is finer than you need, the
5-minute schedule is the usual next stop, and the
cron expression generator will read any of them back to you before you
commit the line.