Cron first Monday of the month: why 0 9 1-7 * 1 fires too often

Both day fields hold a value rather than *, so cron runs the job when either one matches. POSIX words the rule this way: "then any day matching either the month and day of month, or the day of week, shall be matched." This is the trap to check first, because cron accepts the line without complaint.

0 9 * * 1 [ "$(date +\%d)" -le 7 ] && /path/to/job

The minute 0 and hour 9 set the run time to 9:00 AM. The day of month and month are both *, so the weekday 1 decides the day, and cron matches Mondays only. The shell test does the rest. In the crontab line, date +\%d prints the day of the month, [ ... -le 7 ] is true for days 1 to 7, and && runs the job only when that test passes. A week has seven days, so exactly one Monday in each month falls on days 1 to 7.

The backslash in \% is required in a crontab line. The crontab(5) man page says an unescaped percent sign "will be changed into newline characters", and everything after the first one goes to the command as standard input. Without the escape, the command gets cut at the % and the test breaks. After you copy a command from a terminal, the crontab line is where it breaks, because the terminal version has a bare % in it. A script file doesn't have this problem, so the same test can live there with a plain %.

#!/bin/sh
[ "$(date +%d)" -le 7 ] || exit 0
/path/to/job

With the script, the crontab line is just 0 9 * * 1 /path/to/first-monday.sh, with no escape needed. The leading zero from date isn't a problem either. date +%d prints 07 and 08, and [ reads those as plain decimal numbers, so [ "08" -le 7 ] is false, which is what you want. Bash and dash both handle it this way.

systemd can express the whole rule in one line. Its calendar syntax needs the weekday and the day of the month to both match, and the systemd.time(7) page documents the format. In a timer unit, this line fires only on a Monday that falls on days 1 to 7:

OnCalendar=Mon *-*-1..7 09:00:00

The server's time zone is the default for cron, and date reads the same zone, so the 9 AM run and the day check agree. If your server runs on UTC but you think in local time, a 9 AM job runs at 9 AM UTC. Read the cron timezone guide before you pick the hour.