Cron Health panel shows every task red

Every task on Core's Cron Health panel is red, not just one. The single Core cron line isn't firing — debug at the system cron level.

Last updated 20 days ago

Cron Health panel shows every task red

What you're seeing

You open Addons → ImpulseCore → Overview and the Cron Health panel shows every registered task in red — not just one or two. Heartbeats are stale across the board, and nothing has updated since you installed Core.

Why it happens

Core has one cron entry in the system crontab that ticks every 5 minutes. Each tick walks mod_impulsecore_cron_tasks and dispatches due tasks. If every task is red, the runner itself isn't being invoked — the problem is system-level, not per-task.

Fix

Confirm the runner isn't firing. From the WHMCS server shell:
```
SELECT MAX(executed_at) FROM mod_impulsecore_cron_log;
```
A healthy install shows a timestamp within the last 5 minutes. Empty result or a stale timestamp confirms the runner isn't being invoked.
Check the crontab line exists.
```
crontab -l | grep impulsecore
```
You should see one line like:
```
*/5 * * * * /usr/bin/php /path/to/whmcs/modules/addons/impulsecore/cron.php
```
If it's missing, add it. The line lives in the crontab of whichever user owns the WHMCS install (often the Plesk subscription owner, the cPanel user, or www-data/your web user on a vanilla LAMP install — not root).
Confirm the cron user can read WHMCS DB credentials.
The cron user needs read access to configuration.php so it can connect to the WHMCS database. A common failure: a file owned by root:root with mode 600 when cron runs as the web user.
Run the cron script by hand from the same user.
Switch to the user the crontab belongs to and execute the script directly:
```
sudo -u <cron-user> /opt/plesk/php/8.3/bin/php \ /path/to/whmcs/modules/addons/impulsecore/cron.php
```
Replace /opt/plesk/php/8.3/bin/php with your PHP CLI binary. On Plesk: /opt/plesk/php/8.3/bin/php. On cPanel: /opt/cpanel/ea-php83/root/usr/bin/php. On a vanilla LAMP install: /usr/bin/php or whatever which php returns. Any fatal, missing extension, or connection error lands on stdout.
Check system mail or the journal.
```
tail /var/spool/mail/<cron-user> journalctl -u cron --since "1 hour ago"
```
Look for "command not found" (wrong PHP path in the crontab), "permission denied" (file ownership), or PHP fatals.

How to confirm it worked

After fixing the system-level issue, wait for the next 5-minute tick. The mod_impulsecore_cron_log query above should return a fresh timestamp. Refresh the Overview tab — the Cron Health panel turns green over the next few ticks as each task gets a chance to run.

Related issue: only one task is red

If most tasks are green and only one or two are red, the runner is fine — that specific task is failing. See Cron Health: one task is failing.