WHMCS can load in a browser while its cron fails because the two use different PHP binaries or configuration files. Compare both environments before changing the cron schedule or repeatedly running automation.
IN THIS ARTICLE
01 Identify both PHP environments
- In WHMCS, open PHP Info and record the PHP version and Loaded Configuration File path.
- Read the actual system cron command from the hosting control panel or server crontab. Identify the full PHP binary path it invokes.
- Use that same binary to inspect its version and configuration. On an authorised shell, the relevant commands are the selected binary followed by
-vand--ini. - Compare ionCube, required extensions, timezone, memory and other relevant settings in both environments.
- Configure the cron to use the intended compatible PHP binary and configuration, then verify a normal scheduled run.
02 Why changing the website PHP version may not help
A control panel's website PHP selector can change only the web handler. The cron may still invoke a system-wide PHP binary. Use an explicit path supplied by your hosting environment rather than assuming php selects the same version everywhere.
Keep the web and cron timezone aligned. A timezone mismatch can make scheduled activity appear at unexpected times even when both PHP versions can execute the application.
03 Verify the correction
Review Automation Status, the cron report and System Health. Some health results are cached until daily automation runs, so inspect the real execution result instead of immediately repeating the change because a warning remains visible.
If the cron still fails, capture its safe error output and inspect the required extension or file-access problem. Do not expose a public PHP information page or paste the full environment into a ticket; it can contain sensitive paths and settings.
04 Example: inspect the PHP binary used by cron
On an authorised shell, replace /absolute/path/to/php with the exact PHP binary from the current cron command. These diagnostic commands print runtime information without executing the WHMCS cron:
/absolute/path/to/php -v
/absolute/path/to/php --ini
The first command identifies the PHP version and command-line runtime. The second lists the loaded configuration file and additional configuration files. Compare those results with Utilities > System > PHP Info in WHMCS, including required extensions and the effective settings.
If the cron command supplies configuration options such as -c, include the same options in the diagnostic command before the inspection flag. A matching filename alone does not establish matching configuration when additional files are also loaded.
When should you repeat this check?
Repeat it after PHP upgrades, server moves and changes to a private cron directory. Record the known working binary and configuration paths in your maintenance notes so a later administrator does not replace them with an ambiguous default.