The cron job that had not run since March

Every scheduled job I inherit ends the same way: output redirected to the null device, so cron stops emailing. It is sensible, it is universal, and it is how jobs fail for months without anybody noticing.

What silence actually means

A cron entry that succeeds is silent. A cron entry that fails instantly, because the binary it calls does not exist at that path, is also silent. From outside, those two states are indistinguishable, and there is no dashboard anywhere in WordPress that will tell you which one you have.

This bites hardest immediately after a server move, because the paths change. A command line tool installed at one location on the old host and another on the new one will fail on the first scheduled run after cutover and every run after that, while the website itself looks perfect. Imports stop. Queued background work stops. Scheduled reports stop. The first person to notice is usually a customer.

Check it in one minute

1. Run the exact command from the cron entry by hand, as the user cron runs it as, without the redirect. Not a similar command — the exact string.
2. Confirm the binary is where the entry says it is. If it is somewhere else, symlink it rather than editing every job.
3. Check the user has a shell that can execute it at all. Some hosting panels give site users a restricted shell that fails in a way that produces no output whatsoever.

Then stop redirecting to nowhere

Send output to a log file instead, and rotate it. The volume is trivial and it converts an invisible failure into a line you can grep. For anything that matters, have the job record when it last completed successfully, and check that timestamp rather than checking that the job exists.

The general form of this is worth internalising. Any monitoring that only tells you when something fails will not tell you when the thing that reports failures has itself stopped running. Watch for the absence of success, not the presence of errors.