WHMCS Cron Job Setup & Troubleshooting Guide

If you run WHMCS and your invoices stopped generating, reminder emails went silent, or your dashboard shows a red “Cron has not run in the last 24 hours” warning — the WHMCS cron job is almost certainly the culprit. This pillar guide walks you through what the cron does, exactly how to set it up via cPanel or server crontab, how to confirm it’s firing, and how to fix the most common failures hosting providers run into in 2026.

What the WHMCS Cron Job Does (and Why It’s Required)

WHMCS is, at its core, a billing and provisioning engine. But it doesn’t run anything on its own — the application sits idle until something “pokes” it on a schedule. That poke is the WHMCS cron, a single command pointed at crons/cron.php inside your installation directory.

Every time the cron fires, WHMCS checks a long task queue and runs whatever is due. According to the official WHMCS 9 documentation, the cron is responsible for over 35 distinct automation tasks. Here’s a partial map of what breaks if it isn’t running:

In short: no cron = no automation. You’re back to running a billing platform by hand, and that’s exactly the situation WHMCS exists to prevent.

WHMCS Cron Setup via cPanel (The Easy Path)

For 90% of WHMCS owners — anyone whose install lives on a cPanel-powered server — the cron is best added through the cPanel UI. It’s point-and-click, no SSH required.

1. Log in to the cPanel account that hosts your WHMCS installation.
2. Scroll to the Advanced section and click Cron Jobs.
3. Under Common Settings, pick Once Per Five Minutes. (If your host doesn’t allow 5-minute intervals, you must run it at least once per hour — but invoicing will be sluggish.)
4. In the Command box, paste your exact cron command (see the next section for the format).
5. Click Add New Cron Job. Done.

The Exact Cron Command Syntax

WHMCS gives you the exact command in Utilities → Automation Status (click the top-left badge). It’ll look like one of these:

# Standard cPanel cron command (recommended)
php -q /home/yourcpaneluser/public_html/whmcs/crons/cron.php

If you’re editing the server crontab directly via SSH, prepend the schedule:

# crontab -e — runs every 5 minutes
*/5 * * * * php -q /home/yourcpaneluser/public_html/whmcs/crons/cron.php > /dev/null 2>&1

Where to Find the Cron Command Inside WHMCS

1. WHMCS Admin Area → Utilities → Automation Status (or Setup → Automation Settings on WHMCS 7.10 and earlier).
2. Click the top-left status badge.
3. Copy the value shown under Cron Command — that string already contains your correct absolute path and recommended PHP invocation.

WHMCS Cron Setup via Server Crontab (Advanced)

If you’re on a VPS, dedicated box, or your control panel doesn’t expose a cron UI, you’ll edit crontab directly. SSH in as the user that owns the WHMCS files (running it as root is a security mistake — file ownership and permissions will drift).

# SSH as the WHMCS file owner
crontab -e

# Add this line (5-minute interval, full PHP path, silent output)
*/5 * * * * /usr/local/bin/php -q /home/whmcsuser/public_html/crons/cron.php >/dev/null 2>&1

# Save and exit — verify it landed
crontab -l

Finding the Right PHP Path

Different servers ship multiple PHP binaries (CloudLinux Selector, EA-PHP, Plesk handlers). Using the wrong one is the #2 cause of cron failure. Find the right one:

# Find every PHP binary on the box
which -a php
ls -la /opt/cpanel/ea-php*/root/usr/bin/php  # EA-PHP on cPanel
ls -la /opt/alt/php*/usr/bin/php             # CloudLinux PHP Selector

# Confirm what version WHMCS needs
php -v

How to Verify Your WHMCS Cron Is Actually Running

Setting up the cron is only half the job. Until you verify it, you don’t actually know. Here are the three proofs we use during every WHMCS deployment audit:

1. Check the Automation Status Page

WHMCS Admin → Utilities → Automation Status. The top of the page shows the last cron run timestamp. Within 5–10 minutes of a healthy setup, that should refresh.

2. Run cron.php Manually with Verbose Output

This is the single most useful debug command in the entire WHMCS troubleshooting kit. SSH in and run:

php -q /home/whmcsuser/public_html/crons/cron.php all -F -vvv

What each flag does:

• all — execute every task
• -F — force, even if today’s task already ran
• -vvv — maximum verbosity; every error gets printed

You’ll see WHMCS stepping through all 24+ daily tasks, ending with a green [OK] Completed line. Any error message you see here is the real reason your cron is broken — copy it and search for it.

3. Watch the System Cron Log

# RHEL/CentOS/AlmaLinux/Rocky
grep CRON /var/log/cron | tail -50

# Debian/Ubuntu
grep CRON /var/log/syslog | tail -50

You should see your cron.php line being invoked every 5 minutes. If it’s not there at all, your crontab entry was never saved or the cron daemon isn’t running.

Troubleshooting Common WHMCS Cron Failures

Once you know what to look for, almost every WHMCS cron failure falls into one of five buckets. We’ll work through them in the order we actually hit them in production.

Problem 1 — Wrong PHP Path or Binary

Symptoms: jailshell: php: command not found, /bin/sh: php: No such file, or the cron runs but produces no WHMCS log entries.

Fix: use the full absolute path to the right PHP binary.

# Bad (relies on $PATH inside cron, which is minimal)
*/5 * * * * php -q /home/user/whmcs/crons/cron.php

# Good (explicit binary)
*/5 * * * * /opt/cpanel/ea-php82/root/usr/bin/php -q /home/user/whmcs/crons/cron.php

Problem 2 — File or Directory Permissions

Symptoms: Permission denied, blank cron.php output, or “Could not open file” warnings inside WHMCS.

The cron must run as the user that owns the WHMCS files. Mismatched ownership is a classic break.

# Verify ownership matches the cron user
stat -c "%U:%G %n" /home/whmcsuser/public_html/crons/cron.php

# Reset ownership and sane permissions (run as root)
chown -R whmcsuser:whmcsuser /home/whmcsuser/public_html
find /home/whmcsuser/public_html -type d -exec chmod 755 {} \;
find /home/whmcsuser/public_html -type f -exec chmod 644 {} \;
chmod 755 /home/whmcsuser/public_html/crons/cron.php
# configuration.php must be readable but locked
chmod 400 /home/whmcsuser/public_html/configuration.php

Problem 3 — Wrong Interval (Too Slow or Too Fast)

WHMCS expects the cron every 5 minutes. If your host throttles you to every 15 or 30 minutes, the email queue, ticket actions, and job queue will lag visibly. The official guidance: 5 minutes ideal, 1 hour absolute minimum.

You can also over-fire the cron — running it every minute — which triggers WHMCS’s “invocation frequency warning” because individual cron tasks start overlapping themselves.

# Correct
*/5 * * * * /usr/local/bin/php -q /home/user/whmcs/crons/cron.php

# Too slow (works but degraded)
0 * * * * /usr/local/bin/php -q /home/user/whmcs/crons/cron.php

# Too fast (causes warnings)
* * * * * /usr/local/bin/php -q /home/user/whmcs/crons/cron.php

Problem 4 — PHP Version Mismatch Between Web & CLI

This is the trickiest failure in modern WHMCS deployments, especially after a server upgrade or a PHP Selector change. Your web WHMCS runs on (say) PHP 8.2, but cron uses the system default /usr/bin/php which is still PHP 7.4. The cron starts, immediately throws a fatal error, exits silently, and your dashboard says it never ran.

Diagnose it:

# What PHP does cron actually use?
*/5 * * * * php -v > /home/whmcsuser/cronphp.log 2>&1

# Wait 5 min, then check
cat /home/whmcsuser/cronphp.log

If the version printed there doesn’t match what WHMCS Admin → Utilities → System → PHP Info reports, you’ve found the bug.

Problem 5 — Cron Daemon Itself Isn’t Running

Rare but real on freshly imaged VPS hosts.

# Check the cron service status
systemctl status crond     # RHEL family
systemctl status cron      # Debian/Ubuntu

# Start and enable it on boot
systemctl enable --now crond

Pros & Cons of Running Cron Yourself vs Managed Hosting

Best Practices for a Bulletproof WHMCS Cron in 2026

• Log to a file you actually check. Replace >/dev/null 2>&1 with >>/home/whmcsuser/cron.log 2>&1 until your setup is stable, then rotate it.
• Add a watchdog alert. Use UptimeRobot, Healthchecks.io, or a Cronitor heartbeat — WHMCS won’t email you when cron stops; only when it’s been broken >24h.
• Document the exact command. Paste it into your internal runbook with the PHP binary path. Future-you (or your sysadmin) will need it after the next server migration.
• Lock configuration.php to chmod 400. The cron user must read it, nothing else.
• Don’t schedule cron from two places. Pick cPanel or crontab — never both. Duplicate runs trigger the invocation frequency warning.
• Match CLI PHP to web PHP. After every PHP Selector change, re-test cron the same day. (Yes, again — see the version mismatch guide.)

Verification Checklist (Save This)

Real-World Testimonials

Where This Guide Fits — and Where to Go Next

This article is the pillar entry point for everything related to WHMCS cron. If you’re still stuck after the troubleshooting section, jump to the deep-dive that matches your symptom:

Final Verdict

If you take only three things away from this guide: (1) the cron command must be the exact one WHMCS gives you under Automation Status, (2) run it every 5 minutes from a single source, and (3) when it breaks, the first command to run is php -q /path/to/crons/cron.php all -F -vvv — that one line surfaces almost every error you’ll ever see.

For everything specific to the PHP version mismatch error — by far the most common 2026 failure mode — head to our deep-dive: Fix WHMCS Cron PHP Version Mismatch →