1. Open Utilities and Automation Status. Check the most recent invocation and daily completion information rather than relying only on the colour of the status indicator.
2. Open the relevant status badge or report to inspect failed tasks. Use the linked explanation for a specific failure where available.
3. Compare the report time with the server's timezone and the configured daily Time of Day. A daily task may not be due yet.
4. Review the daily actions for the affected area, such as invoice generation, payment capture, suspension or backup. Identify the first missing or failed action.

Confirm that the cron entry exists under the correct account, points to the current installation and uses an executable PHP binary. Check whether the hosting provider has disabled scheduled tasks or whether filesystem permissions prevent access. A migrated or renamed directory commonly leaves an old path in the scheduler.

Compare command-line PHP with web PHP, including the loaded configuration and required extensions. Capture a short diagnostic execution using the documented verbosity options where needed. Keep output private because it can reveal paths, account identifiers and integration details.

Copy the PHP executable path from the actual WHMCS cron entry. Replace the placeholder below with that exact binary, then inspect its version and configuration locations:

/path/to/php -v
/path/to/php --ini

The first command reports the selected PHP version and loaded engine information. The second shows which configuration file and scanned configuration files that executable uses. These commands do not invoke cron.php.

Expected result: you can compare the scheduled process with the PHP environment used by the website. If a different PHP version or configuration is selected, correct the specific cron command or required environment with the hosting administrator. Do not replace the path with whichever php happens to be first in a shell's search path without checking it. Share only the relevant version and paths through the private support ticket.

Inspect the relevant gateway, registrar or server module error and check the corresponding remote system. Use Module Queue for failed provisioning actions, and verify whether the remote action already succeeded before retrying it. Resolve the underlying credentials, package or connectivity issue first.

Avoid applying --force as a general repair command. Forcing due checks or rerunning payment-related work without examining state can create new operational problems. Select a narrowly scoped documented diagnostic action when one is needed.

Allow a normal scheduled run and confirm that the expected task completes. Refresh Automation Status and retain the relevant error and resolution in an internal incident note. Remove temporary verbose logging once the cause is understood.

• Schedule the WHMCS system cron and daily automation
• Review and retry failed WHMCS module actions
• Collect a safe WHMCS module log for troubleshooting
• Set WHMCS suspension and termination automation deliberately

• WHMCS automation status
• WHMCS system cron
• WHMCS: resolve a cron PHP mismatch
• WHMCS module queue

• PHP command-line options