WHMCS Cron Ran but Daily Automation Did Not Finish

Cron Job: Started proves that WHMCS began a run. It does not prove that invoice generation, payment capture, usage polling, suspensions, notices or the final system queue finished. For self-hosted WHMCS, the decisive daily receipt is the later Cron Job: Completed entry in the Activity Log.

When that final entry is missing, do not keep launching the full cron until one happens to pass. Preserve the last recorded running-task marker, reproduce the scheduled runtime and isolate the likely owner with the narrowest safe test. A forced replay can repeat customer-facing automation that already succeeded earlier in the day.

One missing log line changes the diagnosis

WHMCS recommends invoking its system cron every five minutes, while the configured Time of Day controls when daily tasks become due. Those are two clocks: the Linux scheduler can run perfectly every five minutes even though one daily task fails during its assigned hour.

Current WHMCS cron-failure guidance gives the first useful split:

Another application’s scheduler can use a different contract. Compare Nextcloud trigger, dispatcher and job evidence when you need a general model, but do not import its commands or completion semantics into WHMCS.

Reconstruct the scheduled run before testing

Capture the installed command and its owner

Copy the command displayed under Configuration > System Settings > Automation Settings. Then inspect the actual scheduled entry under the account that owns the WHMCS files:

id
crontab -l
command -v php
php --version
php --ini

Record the absolute cron.php path, PHP binary, arguments, output redirection and account. Avoid running a WHMCS billing cron as root merely because an interactive shell is convenient. File access, PHP extensions, home-directory environment and output destinations can all differ from the scheduled account.

Match CLI PHP, timezone and extensions

A web request and a cron command may load different PHP configurations. WHMCS’s timezone troubleshooting specifically requires the web and command-line timezones to agree.

Capture the CLI values without dumping every environment variable:

php -r 'printf("sapi=%s\ntimezone=%s\nini=%s\n", PHP_SAPI, date_default_timezone_get(), php_ini_loaded_file() ?: "none");'
php -m | sort

Compare those results with Utilities > System > PHP Info. A wrong CLI binary can explain a missing extension, lower memory limit or different date.timezone even when the Admin Area looks healthy.

Testing cron.php through a browser is weaker evidence because web-server timeouts and the PHP web SAPI now participate. If that path stalls, investigate PHP-FPM worker and request saturation separately; it does not prove the CLI cron has the same owner. WHMCS also recommends keeping its crons directory outside the document root when possible.

Retain the real scheduled output

An intermittent run that succeeds manually may depend on the Time of Day window, concurrent load, module availability or the scheduled account. WHMCS recommends adding maximum verbosity and retaining output across the real daily window. Store it outside the public document root, restrict access and rotate it after the incident:

install -d -m 0700 /home/ACCOUNT/whmcs-cron-debug
php -q /home/ACCOUNT/whmcs-crons/cron.php all -vvv >> /home/ACCOUNT/whmcs-cron-debug/daily.log 2>&1

Replace both paths with the command WHMCS generated for the installation. Verbose output may contain client, server, domain or module context, so do not paste the whole file into a public issue.

Let the last running-task marker narrow the evidence owner

Usage Stats Update stops before the next marker

WHMCS’s Tenant Usage Metrics timeout guidance ties this marker to connections from WHMCS to configured hosting servers. An old server record, wrong hostname or port, firewall rule, DNS failure or unreachable endpoint can hold the run until PHP’s execution boundary.

Test every server from Configuration > System Settings > Servers and correct or remove stale definitions under change control. Do not globally open management ports or lengthen timeouts until the failing server identity and network path are known.

Executing System Queue runs for an unusual time

According to WHMCS System Queue timeout guidance, built-in database backup generation and archive work can become expensive as the database grows on a resource-restricted server. Measure process runtime, CPU, memory, I/O and destination capacity while the stage is active.

Do not disable the only working backup just to make the completion marker appear. First verify another protected backup path and restore test. A long-running archive and a stuck process are different incidents.

A database error names a narrower concurrency problem

“Database problem” is not a sufficient owner. Connection refusal, a long metadata wait, a deadlock and exhausted capacity need different actions. If process-list evidence shows DDL waiting behind an open transaction, use MariaDB metadata-lock ownership to find the holder before intervening.

When the log records a transaction deadlock instead, follow MySQL deadlock and retry evidence. A retry is safe only when the affected WHMCS or module operation is designed to be retried; billing and provisioning side effects must not be guessed.

PHP or module output stops the process

Fatal memory exhaustion, missing cURL, a module exception and a maximum-execution-time error are separate branches in WHMCS’s system cron troubleshooting index. Preserve the exact exception, task immediately before it, PHP binary and loaded configuration.

Raise a resource limit only after measuring the task and checking the installation’s supported PHP requirements. For module failures, test the named server, registrar or gateway integration and protect credentials in any support bundle.

Isolate one task without replaying the whole day

WHMCS documents all, do and skip in its System Cron reference. Their safety meaning matters:

• all attempts every due task under normal scheduling filters.
• all -F forces tasks regardless of whether they are due or already in progress.
• do --TaskName runs only the named task, enables force by default and does not advance or modify its normal internal schedule.
• skip --TaskName runs the normal set while excluding a named task.

Start with help and the supported task list from the installed WHMCS version:

php -q /home/ACCOUNT/whmcs-crons/cron.php list
php -q /home/ACCOUNT/whmcs-crons/cron.php help do

Before using do, classify the task’s side effects. Exchange-rate lookup and a read-oriented connection test differ from invoice creation, card capture, suspension, termination, reminders or provisioning. A task-level command is narrower, but it is not automatically harmless.

After approval, reproduce only the evidenced task with verbosity:

php -q /home/ACCOUNT/whmcs-crons/cron.php do --TenantUsageMetrics -vvv

Use the exact task name reported by list for the installed version. WHMCS warns that all -F -vvv should not be run more than once in a 24-hour period; treat that full forced replay as an exceptional diagnostic action, not a health check.

Finish with one untouched daily window

After repairing the proven owner, remove temporary forced commands. Keep normal five-minute invocation, wait through the configured Time of Day and capture:

1. The first and final Activity Log timestamps.
2. Cron Job: Completed from the normal run.
3. No repeated invoices, captures, notices, suspensions or terminations.
4. Expected usage, domain, ticket and server-module outcomes.
5. Stable runtime, memory, database and network evidence through the previous failure point.

A green manual command is not the final receipt. Close the incident when the ordinary schedule completes the daily work once, customer-facing effects are correct and the next recurring invocations remain healthy.