Cron every minute: * * * * *

This is the only expression in common use where no field constrains anything. Each of the five positions is a bare asterisk, so the minute matches all 60 values, the hour all 24, the day of month all 31, the month all 12 and the day of week all 7. There is no combination of date and time that fails the test, which is why the count is simply the number of minutes in a day.

The thing that bites at this frequency is overlap. Cron fires on the clock and never checks whether the last copy of the job has finished. A task that normally takes twenty seconds but occasionally takes three minutes will quietly end up with three copies running at once, and if the slow path is caused by load, the extra copies make it slower still. A lock file around the command is not optional here.

Output is the second problem. Cron mails anything a job writes to stdout or stderr to the crontab owner, so a chatty script at this rate produces 1,440 mails a day and, on a box with no mail transport configured, 1,440 log lines complaining that it could not send them. Redirect both streams to a file you rotate, or set an empty MAILTO at the top of the crontab.

Before committing to every minute, check whether the work is actually periodic. Polling a queue once a minute means the average item waits thirty seconds, which is usually worse and more expensive than a long lived worker that blocks on the queue. Cron at this frequency makes sense for cheap idempotent checks, not for anything you would describe as real time.