Why does my cron job work manually but not on schedule?

The overwhelmingly common answer is the environment. Cron runs jobs with a deliberately minimal environment, quite unlike an interactive shell. Your profile scripts are not sourced, so the variables they set do not exist, and the search path is very short. A command that works when you type it fails under cron because the interpreter or tool is no longer on the path.

The reliable fix is to remove the dependency on environment rather than fight it. Use absolute paths for every command and file, set the variables the job needs inside the script itself or explicitly in the crontab, and avoid relying on the working directory, which is not what you probably assume.

Several other causes recur.

• Relative paths in the script. Since the working directory differs, a relative reference resolves somewhere unexpected. Changing directory explicitly at the top removes the ambiguity.
• Output going nowhere. By default cron mails output, and on a machine with no mail configured that output is simply lost, taking your error message with it. Redirecting both standard output and error to a log file is the single most valuable change you can make, converting this from guesswork into reading a file.
• Percent signs in the command, which cron treats specially rather than passing through. They must be escaped, and this bites most often in date formatting.
• A missing newline at the end of the crontab file, which some implementations require for the final entry to run.
• Permissions or ownership, where the job runs as a different user than the one you tested as and cannot read a file or write to a directory.

Adding logging first and then re-running resolves nearly all of these quickly, because the actual error message is almost always specific enough to act on.