Why Are My Episode Emails Sending Slowly?

Benecaster sends email from an internal queue at a deliberately limited rate. If a batch is taking longer than you expected, that’s usually the throttle doing its job rather than something being broken.

This page explains how to tell the difference, and how to pick the right rate.

How the Queue Works

Emails are added to a queue and dispatched in batches by a WP-Cron task that runs every five minutes — twelve times an hour. The Emails per hour setting divides across those runs, so a rate of 300 sends roughly 25 emails every five minutes rather than 300 in a burst on the hour.

At the default rate, a 1,000-subscriber send takes a little over three hours to finish. That’s expected behavior, not a fault.

Admin and security emails bypass the queue and send immediately, which is why a license alert can land instantly while subscriber emails are still working through the backlog.

Is It Throttling or Is It Stuck?

Go to Benecaster → Settings → Email and watch the queue depth over a few minutes.

• Falling steadily — the queue is working. It’s throttling, and it will finish on its own. Raise the rate if you want it faster.
• Static or rising — emails aren’t going out at all. That’s a different problem: see Emails Not Sending.
• Falling, then stalling repeatedly — your SMTP provider is likely deferring messages because the rate is above what your plan allows. Lower it.

That third pattern is the one people misread. A rate set too high doesn’t send faster — it gets messages deferred or blocked by the provider, which is slower than a conservative rate that never trips a limit.

Choosing a Rate

Set the rate to match your SMTP provider’s published limit, then stay comfortably under it.

Providers describe the same thing in different units:

• Mailgun — “sending rate”, already per hour
• Postmark — “messages per minute”; multiply by 60
• SendGrid — listed under your plan details
• Amazon SES — “sending rate” in messages per second; multiply by 3,600

Leave headroom. Other things on your site send mail too — WordPress core, WooCommerce, contact forms — and they all draw on the same provider limit. If your ceiling is 500/hour, setting Benecaster to 500 leaves nothing for anything else.

If you don’t know your limit, leave the default at 300. It’s below the limit of essentially every paid transactional plan.

Why Not Just Send Everything at Once

Three reasons, and they all cost more than the wait:

Providers throttle you back. Exceeding your rate gets messages deferred, and repeatedly exceeding it can get sending suspended.

Spam filters read volume as a signal. A sudden burst from a domain that normally sends steadily looks like a compromised account. Pacing protects your sending reputation, which is far harder to repair than it is to preserve.

Your server has to do the work. Each message means template rendering and an SMTP handshake. Sending thousands in a burst competes with serving your actual site.

Making a Large Send Faster

If you have a genuine reason to move a big batch quickly:

1. Confirm your provider’s ceiling first — this is the real constraint, not Benecaster.
2. Raise Emails per hour to sit just under it, allowing for your site’s other mail.
3. Let it run, then set the rate back down. A raised limit is only worth carrying while you need it.

For a one-off send of a few thousand, it’s usually less trouble to start it and let it finish overnight than to tune the rate and risk tripping a provider limit.

If the Queue Isn’t Moving at All

A queue that never drains, at any rate, points at WP-Cron rather than at email. The dispatch task has to actually fire — on low-traffic sites, WP-Cron waits for an incoming request to trigger it.

See Cron isn’t firing on time, which covers setting up a real system cron to replace WordPress’s request-triggered behavior.