Answer by BillThor for Why crontab scripts are not working?

The most frequent reason I have seen cron fail in an incorrectly stated schedule. It takes practice to specify a job scheduled for 11:15 pm as 15 23 * * * instead of * * 11 15 * or 11 15 * * *. Day of the week for jobs after midnight also gets confused M-F is 2-6 after midnight, not 1-5. Specific dates are usually a problem as we rarely use them * * 3 1 * is not March 1st. If you are not sure, check your cron schedules online at https://crontab.guru/.

If your work with different platforms using unsupported options such as 2/3 in time specifications can also cause failures. This is a very useful option but not universally available. I have also run across issues with lists like 1-5 or 1,3,5.

Using unqualified paths have also caused problems. The default path is usually /bin:/usr/bin so only standard commands will run. These directories usually don't have the desired command. This also affects scripts using non-standard commands. Other environment variables can also be missing.

Clobbering an existing crontab entirely has caused me problems. I now load from a file copy. This can be recovered from the existing crontab using crontab -l if it gets clobbered. I keep the copy of crontab in ~/bin. It is commented throughout and ends with the line # EOF. This is reloaded daily from a crontab entry like:

#!/usr/bin/crontab# Reload this crontab#54 12    *   *   *   ${HOME}/bin/crontab

The reload command above relies on an executable crontab with a bang path running crontab. Some systems require the running crontab in the command and specifying the file. If the directory is network-shared, then I often use crontab.$(hostname) as the name of the file. This will eventually correct cases where the wrong crontab is loaded on the wrong server.

Using the file provides a backup of what the crontab should be, and allows temporary edits (the only time I use crontab -e) to be backed out automatically. There are headers available which help with getting the scheduling parameters right. I have added them when inexperienced users would be editing a crontab.

Rarely, I have run into commands that require user input. These fail under crontab, although some will work with input redirection.