Cron jobs that do not email you 400 times

A cPanel cron job emails you whenever it prints output, so PHP notices and empty success lines can fill your mailbox fast. Redirect standard output and errors to a log file, and keep MAILTO empty only after the job itself is quiet. That combination is what stops hundreds of useless messages without hiding real failures.

Why WordPress schedules need a real crontab

WordPress ships with wp-cron, which only runs when someone visits the site. Quiet sites miss scheduled posts, backups, and subscription renewals. Busy sites can pile up overlapping runs and create race conditions. The reliable fix is to disable the built-in trigger and call wp-cron.php from cPanel cron on a steady interval.

Add define('DISABLE_WP_CRON', true); to wp-config.php, then schedule the PHP binary against the correct document root. One without the other freezes schedules. Leaving both enabled can double-fire the same jobs. Every minute is rarely needed on shared hosting; every five minutes is enough for most shops.

*/5 * * * * cd /home/USER/public_html && /usr/local/bin/php wp-cron.php >>/home/USER/logs/wpcron.log 2>&1

Replace USER with your account name. Keep logs under ~/logs, not inside public_html, so visitors cannot read them. Use the MultiPHP binary that matches the vhost, not a random system path. Do not wget a localhost URL from inside CageFS and expect it to reach your site the way a browser would.

Stop the email flood from stdout

cPanel mails whatever the job writes to standard output or standard error. Redirect both streams to a log file, as shown above, so routine runs stay silent. An empty MAILTO line does not always save you if PHP still prints warnings, so fix the warning or notice at the source when one appears.

A small script that only appends a timestamp is a good first test. Once that line shows up on schedule, you know the crontab is firing before you dig into WordPress itself.

Point cron at the right WordPress tree

Addon domains and subdomains often live outside the main public_html folder. Aim the crontab at the directory that actually holds that WordPress install. Pointing at the wrong tree is how “cron runs” and “nothing publishes” can both be true at once.

After you save the job, wait one or two intervals and check the log. If the timestamp advances and schedules start moving, you are done. If mail still arrives, open the log, clear the PHP message it captured, and the inbox should stay quiet.