How to run an ImpulseCore cron task manually

Invoke any registered cron task synchronously by name. Useful for debugging a failing task, forcing a daily task without waiting, or dry-running a new task while developing a module.

Last updated 20 days ago

How to run an ImpulseCore cron task manually

Core's cron runner ticks every 5 minutes and dispatches tasks whose `next_run_at` has come due. When you want to run one task now — without waiting and without affecting the scheduled cadence — invoke it synchronously from the shell.

The command

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

The handler runs inline. Any output, errors, and stack traces go straight to stdout — much faster to debug than waiting for the next tick and reading the audit log.

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. Replace <task_name> with the registered name — audit_purge, license_refresh, security_collect, cve_feed_refresh, or whatever a module registered.

When to use it

  • Debugging a failing task. The Cron Health panel shows a task amber or red. Run it synchronously to see the full output, not just the summary the audit log captures.
  • Forcing a daily task without waiting. You've just registered a new module with a SecurityCollector and want snapshots now rather than tomorrow. Run security_collect by hand.
  • Dry-running a new task while developing a module. You've added a new task in the manifest and want to confirm the handler wires up before you hand off to system cron.
  • One-off operational work. Force an audit_purge immediately after changing the retention cutoff, rather than waiting for the next daily tick.

What gets written either way

Whether the task succeeds or fails, the runner writes one row to mod_impulsecore_cron_log for the invocation. If you run a task twice in fast succession, you'll see two log rows. Most Core-shipped tasks are idempotent — running them twice does no harm — but module-shipped tasks may not be. Check the module's documentation if you're unsure whether a back-to-back run is safe.

Listing registered tasks

SELECT name, cadence, last_run_at, next_run_at FROM mod_impulsecore_cron_tasks ORDER BY name;

Or look at the Cron Health panel on Core's Overview tab — same data with status indicators.

Alternative: stamp the task to run on the next walker tick

If you don't need synchronous output and don't want to call the script directly, stamp the task's next_run_at to now and let Core's regular runner pick it up within 5 minutes:

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

This runs the task in the same context as a normal scheduled run (same user, same audit attribution as source=cron). The synchronous shell invocation runs in your shell's context — fine for debugging, but anything that depends on cron's user identity may behave differently.

Related