Why didn't the cron job succeed?

It's a question I've spent much of my adult life pondering.

The cron background job wasn't running. On Arch Linux, installing cron does not automatically start the background job. You need to run sudo systemctl enable cronie.service && sudo systemctl start cronie.service.
The command used Bash syntax. Cron executes jobs with /bin/sh by default, which doesn't support all Bash syntax. Notably, the &>> operator for redirecting standard output and error together won't work. You can change the default shell by declaring, e.g., SHELL=/bin/bash at the top of your crontab.
The program required an environment variable that wasn't set. It's common for cron to run scripts in a limited environment, perhaps only defining SHELL, PATH, LOGNAME, and USER. This is true even if you use Bash, since Bash only reads ~/.bashrc when invoked interactively.
The executable wasn't on the PATH. A special case of the above: cron will run your jobs with PATH set to a limited number of locations. You can set PATH in the crontab, or spell out the full path to the executable.
The program's output went into oblivion. On Debian, the output of my cron jobs gets discarded because I haven't configured cron to send email. Annoyingly, the journalctl logs don't even tell me if the command returned an error code or not. Arch Linux's cron is much more helpful: both standard output and standard error are in sudo journalctl -u cronie.service.
The redirection syntax was wrong. mycmd 2>&1 > cron.log seems logical, but it doesn't work: the right order is mycmd > cron.log 2>&1. (To be fair, this one isn't cron's fault.)
The command contained a percent sign. According to crontab(5): "A '%' character in the command, unless escaped with a backslash (\), will be changed into newline characters, and all data after the first % will be sent to the command as standard input." This is true even if the percent sign is in a quoted string!

Why didn't the cron job succeed?

Further reading