Why Artisan works locally but fails from cPanel cron
The website runs on PHP 8.4 while cron resolves php to an older binary. The same repository can then fail only in scheduled tasks with syntax errors or missing extensions. Web PHP and shell PHP are separate runtime paths.
Inspect the cron runtime explicitly
php -v
php --ini
php -m
Run these through the same account and executable path used by the scheduled command. Compare the version, loaded configuration, and extensions with the application's requirements. Do not expose a public phpinfo page just to inspect the runtime; it can reveal configuration details unnecessarily.
Use an explicit command context
A cron entry should change into the application directory and invoke the intended PHP binary by absolute path. Some hosts also require a specific configuration scan directory. Use the host's actual documented paths rather than copying paths from another provider.
Log command failures into a private, bounded log and verify a successful scheduled execution. A command working in an interactive shell does not prove cron loads the same shell initialization or environment variables.
Test a harmless Artisan command first, then the intended scheduled operation. Confirm the database connection and storage permissions under that runtime. Keep the selected web runtime and account-wide runtime changes scoped carefully: changing a shared account default may affect other applications hosted under the same account.