Every minute on a restricted day
* * 1 * *0 0 1 * *This is one of the most common and most expensive cron accidents. When the minute and hour fields are both * but a date field — day-of-month, month, or day-of-week — is restricted, the job does not run once on that day. It runs every minute of that day, all 1,440 of them.
* * 1 * * is the classic. The author almost always meant "on the 1st of the month", a single run, and wrote the day-of-month field correctly — but left the minute and hour as stars, so the job fires at 00:00, 00:01, 00:02, all the way to 23:59 on the 1st. That is 1,440 executions where one was intended, which can mean 1,440 emails, 1,440 API calls, or 1,440 overlapping copies of a heavy job.
The fix is almost always to pin the minute and hour: 0 0 1 * * runs once, at midnight on the 1st. The same correction applies to every variant — * * * * 1 should usually be 0 0 * * 1 for a weekly Monday run, and * 9 * * * (every minute of the 9 AM hour, 60 runs) is usually meant to be 0 9 * * *. Whenever you restrict a day, ask whether you also meant to restrict the time.
This warning is deliberately more specific than the general freq-extreme note, and it suppresses that note when it applies, because "every minute on a restricted day" is a sharper, more actionable diagnosis than "this runs a lot". If you truly want a job to run every minute of a particular day — a monitoring sweep on the 1st, say — then the expression is correct and you can ignore the warning; but confirm it, because the odds are you wanted a single run.
Watch the linter flag it live — the finding below appears the moment the expression is entered: