Capturing output, MAILTO, and a log-checking checklist
cron usually fails silently. If your expression is correct according to this tool but the job still doesn't run, the problem is likely not the expression but the runtime environment. Here is how to narrow down the cause, step by step.
Save output to a file. By default cron mails a job's standard output and standard error, but if mail isn't configured, they simply vanish. Append >> /var/log/myjob.log 2>&1 after the command to capture both stdout and stderr in a log file, and you can immediately see what happened.
Get notifications with MAILTO. Adding MAILTO="you@example.com" at the top of the crontab forwards job output and errors to that address. It's the easiest safeguard against silent failures. Conversely, if you don't want mail, empty it with MAILTO="".
Check the system logs. On Debian/Ubuntu-based systems use grep CRON /var/log/syslog, and in systemd environments use journalctl -u cron (or crond) to confirm whether cron triggered the job. An important distinction here is that 'whether it attempted to run' and 'whether the script succeeded' are different things.
Finally, a checklist of common causes. ① Did you specify all commands and files with absolute paths? ② Did you declare the necessary PATH in the crontab? ③ Does the script have execute permission (chmod +x)? ④ Did you put the job in the correct user's crontab (root and a regular user's crontab are separate)? Check these four, and validate the expression itself again with this explainer.