WHMCS Cron Job: Setup, Troubleshooting, and Monitoring

WHMCS without a working cron is a billing system that doesn't bill. A single cron script controls everything: invoice generation, domain renewals, overdue account suspension, client notifications. It needs to run every five minutes. When it stops, nothing crashes, nothing throws an error. Clients just stop receiving invoices, domains quietly expire, and cancelled accounts keep running on your dime.

Setting it up is the easy part. Keeping it running is where things go wrong. A PHP upgrade breaks the binary path. A server migration drops the crontab entry. The MySQL socket changes after a database move. And WHMCS won't alert you. You have to manually check the Automation Status page to find out.

What WHMCS schedules through cron

WHMCS runs more background automation than most panel software. The official recommendation is every five minutes, minimum every hour. Here's what rides on that one cron entry.

Billing and invoicing. WHMCS generates invoices automatically based on due dates, sends payment reminders, processes recurring payments through stored gateways, and handles overdue suspension and termination sequences. A missed cron run means invoices don't go out on time, payment retries don't fire, and clients stay active past their billing cutoff.

Domain and SSL automation. Domain renewal reminders, expiration warnings, WHOIS lookups, and SSL certificate renewals all depend on cron. Without it, a client's domain can expire without a single reminder email. Same for SSL: the cert lapses, the browser shows a warning, and the client calls your support instead of getting an automated renewal.

Provisioning and termination. New orders trigger server provisioning through modules (cPanel, Plesk, DirectAdmin). Cron processes the queue. Overdue accounts get suspended and eventually terminated on schedule. Without cron, orders sit in pending and cancelled accounts keep running, costing you resources.

Support and notifications. Ticket escalation rules, automated replies, email piping, client notifications about service changes. All cron-driven. Marketing emails and mass announcements also get queued through cron.

Check your WHMCS Automation Status under Utilities > Automation Status in the admin area. It shows the last time cron ran and flags any problems. If the timestamp is older than 10 minutes, something is broken.

Setting up the WHMCS cron job

WHMCS provides the exact cron command in the admin panel. Go to Utilities > Automation Status and copy the command shown there. The standard format:

*/5 * * * * php -q /home/user/public_html/whmcs/cron/cron.php

Replace the path with your actual WHMCS installation directory. The -q flag suppresses PHP's HTML headers in output.

Via SSH (server crontab)

If you have SSH access, edit the crontab directly:

crontab -e

Paste the command, save, done. This is the most reliable method. WHMCS cron runs locally, no network involved, no timeouts from web server limits.

Via hosting panel (cPanel, Plesk)

Most WHMCS installations sit on servers managed through cPanel or Plesk, since hosting providers are the primary audience. In cPanel, go to "Cron Jobs," paste the command, set it to every 5 minutes. Plesk has it under "Scheduled Tasks."

One thing to watch: some shared hosting providers cap cron frequency at once per 15 minutes or once per hour. WHMCS works with that, but billing and provisioning will be slower. Clients waiting for a new hosting account might sit on a "pending" screen for an hour instead of getting provisioned in minutes.

Via HTTP (Webcron method)

WHMCS also supports triggering cron over HTTP. The URL is typically:

https://your-whmcs.com/cron.php

By default, WHMCS restricts HTTP cron access by IP. Go to Setup > General Settings > Other and add the IP of your external cron service to the "Cron HTTP Access Restriction" field. Without it, the cron call returns a 403.

HTTP triggering has one advantage: it works without SSH, without a crontab, and without a hosting panel. An external service hits the URL on schedule, WHMCS processes the queue. This is the same approach that Nextcloud, PrestaShop, and WooCommerce use for their background tasks.

Common cron problems in WHMCS

WHMCS runs on PHP, but the command-line PHP and the web server PHP are not always the same thing. Most WHMCS cron issues trace back to this mismatch.

Wrong PHP path. The php command in crontab might point to an older PHP version or a different binary altogether. After a PHP upgrade, the symlink can break. Use the full path instead:

*/5 * * * * /usr/local/bin/php -q /home/user/public_html/whmcs/cron/cron.php

Check which PHP your server uses with which php or ask your host for the CLI path. WHMCS 8.x needs PHP 8.1 at minimum.

ionCube not loaded for CLI. WHMCS files are encoded with ionCube. If the CLI version of PHP doesn't have the ionCube loader installed, cron fails silently. The web version works because the loader is configured for the web SAPI but not the CLI one. Fix: check php -m | grep ionCube from the command line. If it's not there, add the loader to the CLI php.ini.

MySQL connection issues. After a database migration or server move, the MySQL socket path can change. Web requests connect through a different socket than CLI scripts. WHMCS cron fails with a database connection error, but there's no visible output unless you redirect cron output to a log file:

*/5 * * * * /usr/local/bin/php -q /home/user/public_html/whmcs/cron/cron.php >> /home/user/logs/whmcs-cron.log 2>&1

403 on HTTP cron. If you're triggering cron via URL and getting a 403, it's almost certainly the IP restriction. WHMCS blocks all HTTP cron requests from IPs not listed in the admin panel. Add the calling IP to Setup > General Settings > Other > Cron HTTP Access Restriction. Cloud Cron's IPs are listed on our IPs page. Add them all and you're set.

These aren't rare edge cases. They come up in every WHMCS community forum thread about cron problems. For admins who manage dozens of WHMCS instances for reseller clients, manually checking each one's Automation Status page every day isn't realistic.

Monitor WHMCS cron with WatchCron Cloud Cron

WHMCS shows when cron last ran on the Automation Status page. That's it. No email if it stops, no Slack notification, no alert of any kind. You find out when a client asks why they didn't get an invoice, or when a domain expires without a single renewal reminder.

Cloud Cron does two things at once: triggers your WHMCS cron automatically and monitors every run. You give it your cron.php URL, pick a schedule, and Cloud Cron calls it from outside your server on time, every time. No SSH, no crontab to manage, no dependency on your hosting provider's scheduler.

The setup is straightforward. Add WatchCron's IPs (listed on our IPs page) to the WHMCS HTTP access restriction list so it doesn't block the requests. Paste your cron URL into Cloud Cron. Set the interval to every 5 minutes using a cron expression or pick from preset schedules. Cloud Cron supports flexible scheduling: every 5, 10, 15, 30 minutes, hourly, or any custom cron expression if you need something specific.

Every call gets logged. You see the full history: HTTP status codes, response times, timestamps. If the endpoint returns an error, times out, or becomes unreachable, WatchCron sends an alert through Slack, Telegram, email, or any of 20+ notification channels. You configure a grace period so a single slow response doesn't trigger a false alarm, but two or three missed runs in a row will.

For servers where CLI cron already works, heartbeat monitoring adds a safety net without changing the trigger. Append a ping after the cron command:

*/5 * * * * /usr/local/bin/php -q /home/user/public_html/whmcs/cron/cron.php && curl -fsS https://ping.watchcron.com/your-monitor-id > /dev/null

If cron.php fails or the server goes offline, the ping doesn't fire, and WatchCron alerts you after the grace period. Your existing cron setup stays exactly the same. One extra curl call is the only change.

WHMCS is one of those platforms where cron failures cost real money. A missed invoice run delays revenue. An expired domain without renewal reminders means a support ticket and possibly a lost client. WooCommerce, Magento, and PrestaShop have similar dependencies, but in WHMCS the stakes are higher because you're managing other people's infrastructure, not just a storefront.