Skip to main content

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 or the warm-up 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.

Setting Default Range
Emails per hour 300 10–2,000

Emails per hour is a ceiling, not a target. Benecaster never sends faster than it, and sends more slowly while your address is warming up (see below). Once your address is warm, a 1,000-subscriber send at the default rate takes a little over three hours to finish. That’s expected behavior, not a fault.

Feed URL reset emails, password resets, security alerts and anything sent to a site admin bypass the queue and the warm-up, and send immediately. That’s 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 or warming up, and it will finish on its own. Check the Sending Warm-up section on the same screen before raising the rate: while it shows a daily limit, a higher rate won’t send any 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.

A New or Quiet Address Is Warming Up

The other reason a queue is slow is that your sending address hasn’t built up a sending reputation yet. Benecaster limits how many emails a From domain sends per day until it has, starting small and roughly doubling each day it sends. On plain host mail that starts at 50 a day and never goes above 2,400 a day. With an email service connected it starts at 500 and climbs to your Emails per hour rate within a few days. Why a New Domain Should Send Email Slowly has the full numbers and the reasons.

Two situations lead here:

  • A brand-new address. A new site, or a first large send such as a migration.
  • An address that has been quiet. If it sent nothing at all for 30 days or more, for example between seasons, it’s eased back in over three sending days. You haven’t done anything wrong, and it isn’t starting over.

Settings → Email → Sending Warm-up states the exact limit for today. When Support Mode is on, the Debug Log also records each time the warm-up held emails back, with the limit and the reason.

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.

A provider’s limit isn’t the only ceiling. While your address is warming up, the warm-up sets a lower daily limit whatever this setting says, and you don’t need to lower the rate yourself to protect a new domain.

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. On plain host mail, connect an email service. It’s the one change that makes a real difference. It shortens the warm-up from about a week to a couple of days, and raising Emails per hour won’t speed up host mail while it’s warming up. SMTP Setup and Configuration shows how.
  2. With an email service, confirm your provider’s ceiling first. That’s the real constraint, not Benecaster. Raise Emails per hour to sit just under it, allowing for your site’s other mail, and set it back down when the send is finished.
  3. Only skip the warm-up if the address is already established. With a service connected, Send at the full rate now, skipping the warm-up appears under Sending Warm-up. It’s for an address that already sends plenty of email with a good reputation. On a new address it’s the quickest way to get your mail marked as spam.

For a one-off send of a few thousand, it’s usually less trouble to start it early and let it finish 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.

See Also

Need this built rather than just documented? See our services →