Cron Health shows one task failing while others are green

What you're seeing

The Cron Health panel on Core's Overview tab shows most tasks green, but one (or a few) sitting amber or red. Amber means the task is overdue (>2× its cadence since last run); red means it hasn't run in >4× its cadence.

Why it happens

Core's runner is invoking the task on schedule, but the task's handler is throwing an exception. Core captures the exception and writes an audit entry under the module's slug with severity error, then moves on. The task's last_run_at doesn't advance because the run didn't complete successfully — that's why the panel shows it as stale.

Common causes:

• The module that originally registered the task was uninstalled, but its row in mod_impulsecore_cron_tasks wasn't cleaned up. The handler class no longer loads.
• The module is still installed, but the handler class was renamed during an upgrade and the task name in the cron registry now points at nothing.
• The task is doing real work that takes longer than the 5-minute walker timeout — it gets killed mid-execution every tick.
• The handler depends on a remote API (license server, NVD, a customer host) that's been unreachable.

Fix

1. Find the exception in the audit log. Open Addons → ImpulseCore → Audit. Filter to severity error and search by the task name. The most recent entry's context JSON blob has the exception class, message, and a short stack pointer.
2. Run the task synchronously to see full output. This is faster than waiting for the next tick:

   /opt/plesk/php/8.3/bin/php \ /path/to/whmcs/modules/addons/impulsecore/cron.php \ --task=<task_name>

   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. The handler runs inline; any error message and stack trace land on stdout.

3. Match the cause to one of these.
   • "Class not found": Module that owns the task is gone but the row is orphaned. Delete it: DELETE FROM mod_impulsecore_cron_tasks WHERE name = '<task_name>';
   • Method missing on the class: Handler was renamed in an upgrade. Re-activate the module's addon entry to re-register current task names.
   • 5-minute walker timeout: Handler is doing too much per run. Split or batch the work; some modules ship a dedicated cron line for high-frequency jobs.
   • External API failure: Usually transient. Check the audit log for the affected upstream — for the Security pipeline this is often a CVE feed.
4. Force the next run. Once you've made the fix, stamp the task to run on the next 5-minute tick rather than waiting for its normal cadence:

   UPDATE mod_impulsecore_cron_tasks SET next_run_at = NOW() WHERE name = '<task_name>';

How to confirm it worked

The next time the runner ticks, the task's last_run_at advances and the Cron Health panel turns green for that row. The audit log stops emitting error entries for it.

Related

• Cron Health panel shows every task red
• How to run an ImpulseCore cron task manually