Day-of-month and day-of-week both restricted
0 0 13 * 50 0 13 * *This is the single most misread rule in cron, and it is written into the standard itself. Fields three (day-of-month) and five (day-of-week) are the only two that each independently select a day. When both are restricted — meaning neither is * — the daemon runs the job whenever either field matches. It takes the union of the two, not the intersection.
Say you want a job on Friday the 13th. The intuitive 0 0 13 * 5 does not mean "the 13th if it is a Friday". Cron reads it as "midnight on the 13th or midnight every Friday" — roughly 56 runs a year instead of the one or two you intended.
The mirror case trips people just as often. 0 0 1-7 * 1, written hoping for "the first Monday of the month", actually fires on the 1st through 7th of every month and on every Monday. The only time cron treats the combination as you might expect is when one of the two fields is *: then only the restricted field applies, and there is no surprise.
The fix is to restrict just one field and move the other condition into your code. For Friday the 13th, schedule 0 0 13 * * — every 13th — and start the script with a guard that exits unless the weekday is Friday, for example [ "$(date +\%u)" = 5 ] || exit 0. For the first Monday, schedule 0 0 1-7 * * and exit unless today is Monday. This keeps cron doing what it is good at — hitting a date — and leaves the conditional logic where it can be read and tested.
Because the union behaviour is standardised, every mainstream cron implementation does this. It is not a bug you can configure away; it is a rule to design around.
Watch the linter flag it live — the finding below appears the moment the expression is entered: