How to fix "/bin/sh: php: command not found" in cron jobs

/bin/sh: php: command not found

Common causes

• Cron's default PATH does not include where PHP is installed, such as /usr/local/bin or /opt/cpanel/ea-php83/root/usr/bin
• On cPanel/EasyApache or CloudLinux, each PHP version has its own binary path, and the plain php name may not exist for cron
• The command relies on an alias or a PATH set in ~/.bashrc or ~/.bash_profile, which cron does not load
• PHP is not installed for the CLI at all on that server (only PHP-FPM)
• Using wp, composer or artisan by name, which have the same PATH problem

How to fix it

1. Find the full path to PHP. In SSH run which php and php -v, or command -v php. Note the full path, e.g. /usr/bin/php or /usr/local/bin/php.
2. Pick the right version on cPanel. For a specific version use /usr/local/bin/ea-php83 or /opt/cpanel/ea-php83/root/usr/bin/php (EasyApache), or /opt/alt/php83/usr/bin/php on CloudLinux. The host's documentation lists the exact path.
3. Use absolute paths in the cron line. Write the full PHP path and the full script path, e.g. /usr/local/bin/php /home/user/public_html/cron.php. Do not rely on the current directory.
4. Or set PATH at the top of the crontab. Add PATH=/usr/local/bin:/usr/bin:/bin as the first line of crontab -e so every job finds php, composer and wp.
5. Capture output to verify. Append >> /home/user/cron.log 2>&1 to the job, wait for it to run, then read the log for the next error, if any.
6. Match the site's PHP version. Run the cron binary with -v and compare with the site's version in the panel. A CLI on an older PHP causes different errors (such as Composer platform check failures).

crontab -e

PATH=/usr/local/bin:/usr/bin:/bin

# every 5 minutes, explicit PHP version (cPanel EasyApache path; check your host)
*/5 * * * * /opt/cpanel/ea-php83/root/usr/bin/php /home/user/public_html/artisan schedule:run >> /home/user/cron.log 2>&1

# WordPress cron via WP-CLI
*/15 * * * * cd /home/user/public_html && /usr/local/bin/wp cron event run --due-now >/dev/null 2>&1

How to stop it happening again

• Always use absolute paths for binaries and scripts in cron
• Log cron output to a file for at least the first few runs
• Re-check cron PHP paths when changing the site's PHP version