Cron & Background Processing

PrimoCRM does all of its heavy work in the background: campaign sends, sequence drips, and automation steps are processed by scheduled workers, never in the page request. Those workers run on WordPress cron, so reliable cron is what keeps your email going out on time. This page explains how it works and how to make it solid.

How PrimoCRM uses cron

PrimoCRM registers two custom schedules and a small set of background workers:

Worker	Runs	Job
Campaign email sending	On demand (only while a campaign has pending emails)	Delivers a campaign in throttled batches
Sequence processing	Every minute	Sends due sequence emails
Automation processing	Every minute	Advances contacts through automation steps
Queue health check	Every 5 minutes	Recovers stuck emails and re-triggers stalled campaigns

Each worker claims a batch of work, honors a time budget so it never exceeds your host’s limits, and reschedules itself. The 5-minute health check is a safety net: if a send stalls, it nudges it back into motion on the next tick.

Why reliable cron matters

WordPress ships with a pseudo-cron that only fires when someone visits the site. On a busy site that is fine. On a low-traffic site, hours can pass with no visits, so scheduled sends do not run until the next visitor arrives. The symptom is a campaign that sits at “sending” and drips out slowly or not at all.

The fix is to replace the visitor-triggered pseudo-cron with a real cron that fires on a fixed schedule, ideally every minute.

Check whether cron is running

Open PrimoCRM then Settings and look for the system or cron status, which reports whether the workers are scheduled and when they last ran.
Or install a helper plugin such as WP Crontrol and confirm the primocrm_process_sequences, primocrm_process_automations, and primocrm_queue_health_check events are present and firing.

If a campaign is stuck and your site gets little traffic, cron is almost always the cause.

Set up a real cron (recommended)

Two steps: turn off the WordPress pseudo-cron, then add a real cron that runs every minute.

1. Disable the pseudo-cron

Add this to wp-config.php, above the “That’s all, stop editing” line:

define( 'DISABLE_WP_CRON', true );

This stops WordPress from triggering cron on page loads, so your real cron is the only trigger.

2. Add a real cron every minute

Pick whichever matches your hosting.

WP-CLI (best, if you have shell access):

* * * * * cd /path/to/wordpress && wp cron event run --due-now >/dev/null 2>&1

PHP binary (also great with shell access):

* * * * * php /path/to/wordpress/wp-cron.php >/dev/null 2>&1

cPanel: open Cron Jobs, set the schedule to every minute (* * * * *), and use one of the commands above with the full path to your site.

No shell access (shared hosting)? Use a free remote cron service such as cron-job.org to call your cron URL over HTTP every minute:

https://yoursite.com/wp-cron.php?doing_wp_cron

Register at the service, add that URL, set the interval to 1 minute, and save. This calls WordPress cron from the outside on a fixed schedule.

Troubleshooting

A campaign is stuck at “sending”. Almost always cron. Confirm a real cron is firing every minute and that DISABLE_WP_CRON is set. The 5-minute health check will resume the send once cron runs.
Automations or sequences run late. Your cron interval is too long, or pseudo-cron is waiting on visitors. Move to a real 1-minute cron.
Nothing sends at all. Separately from cron, confirm your sending method is configured and a test email arrives. Cron controls when work runs; the mailer controls whether it delivers.
Shared host CPU limits. The workers are time-budgeted and back off under load, so they are safe on shared hosting. If your host still complains, a slightly longer interval (2 to 5 minutes) reduces frequency at the cost of promptness.

See also Requirements for PHP and server prerequisites, and Sending and Deliverability for the mailer side.