If you’re running FluentCRM (or really any WordPress-based CRM), you may have run into a frustrating situation where your automated emails just… don’t go out when they’re supposed to.

And the weird part? Sometimes everything looks fine on the surface. You’ve done what you’re supposed to do. But the emails still go out late, or not at all.

I had a client run into this recently. His emails weren’t triggering on time, but the moment he logged into the WordPress backend, they’d suddenly all fire at once. Classic symptom. And there are two separate reasons this can happen — most people only know about one of them.

Let’s cover both.

The First Problem: WordPress Cron Isn’t a Real Clock

Here’s something a lot of WordPress site owners don’t realize: WP-Cron — the built-in scheduled task system — doesn’t actually run on a real clock.

By default, it’s traffic-based. Meaning it only runs when someone visits your site. So if you have an email scheduled to go out at 9am but nobody hits your site until noon, guess when that email goes out?

Right. Noon.

If your site doesn’t get consistent traffic (and most business sites don’t get traffic at 3am, for example), your scheduled tasks are essentially just waiting around for a visitor to show up before they’ll fire.

The fix here is to disable WP-Cron and replace it with a real server-side cron job. In your wp-config.php, you add a line to disable the WordPress version:

define('DISABLE_WP_CRON', true);

Then you set up a crontab entry on the server itself to ping WordPress’s cron system on an actual schedule — I typically use every 5 minutes. Most modern hosts make this easy to set up right in their control panel. If you’re on xCloud (which is what I use for my Concierge clients), there’s an option for this built right in.

That fixes problem one. But here’s where it gets trickier.

The Second Problem: WordPress Memory Limits (and Why They’re Sneaky)

This one trips people up because it’s less obvious, and frankly, the symptoms look identical to the first problem.

WordPress has its own PHP memory limit, and it can be completely separate from what your server actually has available. You might have a VPS with 16GB of RAM and a hosting panel showing 256MB of PHP memory… but WordPress itself might still be running at 40-64MB, which is the old default.

Why does this matter for FluentCRM specifically? Because when the cron job fires, WordPress loads up a bunch of front-end processes. If your memory limit is too low and you’ve got a bunch of plugins running, WordPress can run out of breathing room before FluentCRM even gets a chance to do its thing. The email just silently fails. No error. No log entry. Nothing.

That’s the fun part. It just… doesn’t work, and you have no idea why.

The solution is to explicitly set the memory limit in wp-config.php:

define('WP_MEMORY_LIMIT', '256M');

Don’t rely on what your hosting control panel shows — set it directly in the config file to remove any ambiguity. For most of my Concierge clients, I set it to 512MB or higher depending on the complexity of their setup. I’ve had sites that needed a full gigabyte to run reliably with all their plugins in play.

(Side note: if you’ve ever opened the Gutenberg editor and gotten a fatal error out of nowhere, low memory limit is often the culprit there too.)

Check Both — Don’t Assume One Fix Is Enough

This is the part that catches people. They fix the cron issue, emails start working, and they think they’re done. But a few weeks later the problems come back, or they show up inconsistently, and they’re back to square one.

Both of these need to be addressed. The cron fix ensures tasks fire on schedule. The memory fix ensures FluentCRM actually has the resources to complete the job once the cron fires.

I had a client recently who was on Rapid Hosting — not a bad host by any means — and still ran into this exact situation. Adding that one line to the config file fixed it entirely.

If you’re dealing with delayed sends and can’t figure out why, start here. Check both. Nine times out of ten, that’s all it is.