Schedule that can never run

Cron will happily accept a schedule for a date that does not exist on the calendar, and then never run it. When every selected combination of day-of-month and month is an impossible date, this error fires — the job is dead on arrival.

The textbook case is 0 0 30 2 *: February 30th. There is no such day in any year, so the job never runs. February 29th is different — it is a real day on leap years — so 0 0 29 2 * is not never-fires; it is flagged instead as leap-day-only, because it does run, just rarely. The check caps February at 29 precisely so it does not wrongly condemn a valid leap-day schedule.

It also catches combinations across multiple months where none of them has the day: 0 0 31 2,4,6 * selects the 31st of February, April and June, and not one of those months has a 31st, so the whole schedule is impossible. If even one selected month does have the day, the job can run and the softer dom-unreachable-months warning applies instead — never-fires suppresses that warning so you do not get two reports for the same expression.

The fix is to choose a date the month actually has. For a February job, 28 is always safe (0 0 28 2 *); 29 runs only on leap years. For "the last day of the month" across all months, standard cron has no token — use your dialect's L if it has one, or run daily and exit unless tomorrow is the 1st. Because a never-fires schedule produces no runs and no error at load time on most systems, this is exactly the kind of silent failure a linter is for.