Last Updated on
Newsletter sends out your newsletters at the speed you set on main settings, measured in emails per hour, and splitting the whole job in smaller tasks running every 5 minutes.
If your newsletters get stuck into status “sending (0/nnn)” or if the max speed you set is not reached there could be few optimizations you need to apply.
If you have a CDN active (for example Cloudflare), the service could cache the calls to
wp-cron.php totally blocking the WordPress scheduler. Please, be sure to add an exception for this file in your CDN configuration (or ask the provider to add it for you).
The WordPress cron (or WordPress scheduler)
WordPress has an internal cron which activates Newsletter every five minutes so it can sends out your newsletters at the specified speed. If that scheduler fails to activate Newsletter a lower speed or even a total bock is experienced.
The Newsletter status panel should report a warning about your not correctly working WordPress cron (which few stats).
To make the cron work correctly here two solutions you should try.
1. Using your provider control panel
Many providers have in their control panels the ability to setup a cron job. A cron job is something that is executed periodically.
The provider can help you in setting up all that, ask their support.
The command to be executed every 5 minutes is:
php [path to your blocg]/wp-cron.php
php command could be different, for example
php72 or like. You should ask the provider.
This is the preferred way to trigger the cron since it usually does not suffer from timeout problems.
Alternatively you can use a different command:
wget --delete-after http://www.yourdomain.com/wp-cron.php
Be sure to use the correct protocol,
You can load that address in a browser (
http://www.yourdomain.com/wp-cron.php) to see if a blank page is returned (it’s ok) or if there are errors reported (the address is not correct, PHP errors and like).
Note: commands above are lighter than a web page visit in your blog (when not sending newsletters). I image your provider has resources to deliver 12 page visits in an hour, so there are no reasons to not setup that command. Anyway if your provider refuses to setup that cron job, you can use the second method below.
2. Using an external system
An external service can activate the WordPress cron calling the address
http://www.yourdomain.com/wp-cron.php every 5 minutes.
There are paid and free services, search on Google “online cron service”.
Here few services we successfully tried:
- www.easycron.com (see this post – they have specific instructions for Newsletter plugin)
- www.cron-job.org (see this post)
If you setup an external cron trigger with one of the above methods (use only one of them!), you can stop WordPress trying to auto-trigger the internal scheduler setting on wp-config.php:
That does not disable the scheduler, just disable the WordPress auto-activation! The status panel could report a notice about this setting, it’s ok.
If you have a multisite installation, the external cron trigger should be setup for each of your blog and you can use only the
curl methods (it’s possible to create more efficient and sophisticated scripts, you should ask a developer).
How many newsletters can I send (at the same time)?
You can create and send how many newsletters you want. Each newsletter is set on “sending” status and from the older to the newer the emails (one per targeted subscriber) are generated and sent. Those emails create an global email flow which is managed by the delivery engine (with the configured speed), described below.
The Delivery Engine Speed
The delivery engine speed (measured in emails per hour) can be configured on Newsletter configuration panel.
Since the delivery engine runs every five minutes if you set 100 emails per hour about 8 emails are sent on each run. Sometime you can experience a speed lower than what you set. There are a number of tech reason for that, explained later.
PHP execution timeout
Sending emails can be a slow process, specially if the mail service is slow. So Newsletter must check if the process is reaching the PHP execution timeout and stop it self to avoid problems. You can see if that is happening, enabling on diagnostic panel the main log at info level and look at the log files for a “time limit reached” line.
On shared hosting PHP time limit cannot be raised (usually), on dedicated or virtual server it can be raised.
Tech note: for who think the PHP time limit can be changed with a
set_time_limit() call, remember that PHP (most of the times) is ran as fastcgi process and the fastcgi controller will kill it if it take too longer to end. May be other tech tricks can be used… but for safety the plugin only keeps an eye on this timeout and tries to avoid to pass it.
To get over those problem, the delivery process should be run using a CLI command and not as a webserver process. See below how to trigger the WordPress cron.
If the general performance of your server can support 100 email every 5 minutes, even if you raise the engine speed that is your top limit. Nothing else can be do than changing the server. Server performances are determined by CPU, memory, network speed, disk speed and so on.
Is your blog ready to send email?
A blog can send emails in a reliable fashion if the provider has configured a good email system for his customers. Some hosting provider, specially with shared web spaces, have a inefficient mail service which permits only tens of mails per day (it means it will take tens of days to send to a 1000 subscriber list).
Other provider totally disable the mail system in their server.
Big player, anyway, like Hostgator, Dream Host and so on, let you to send a reasonable number of emails from your blog, state that you are able to “throttle” them. It means you must respect the provider limit, for example not more than 100 emails per hour.
GoDaddy, to cite one of the most used providers, has a strict limit of 250 emails per day (not per hour) if things has not changed and it requires the use of an SMTP.
The use of an external SMTP can be a good choice: Sendgrid, Mailgun, Amazon SES, Sparkpost, Elastiemail, Mailjet and so on.
The cron system is working?
A cron system is something that works even if not one is looking at the blog. A cron system can wake up the blog and their plugin regularly, so they can take some actions (like send emails or publish scheduled posts).
WordPress cannot have a real cron system because PHP cannot. The WordPress team, anyway, find a way to emulate a cron system because the need to trigger future or regular event to make the blog work correctly. For example to publish a scheduled post.
Newsletter Delivery Engine relies on WordPress cron system, so we must be sure it is working. When this system does not work as wanted?
- On very low traffic sites
- On sites with cache systems
- On sites with the cron disabled (one click installed blog on Aruba.it for example)
- On sites “blocked” with basic authentication, ip filtering, cookie filtering or other filters which blocks the call to wp-cron.php
Without explain the technical reason of that, let me to indicate the solutions.
First you need to be sure the cron is not disabled (see exceptions below) with a
wp-config.php file. If there is such line of code, delete it. Then be sure you are not blocking the
wp-cron.php calls with basic authentication or something like. If you see to keep the blog protected, at least unlock the
To test the
wp-cron.php call, try to load it directly from your browser with something like:
Second you should be sure the cron is triggered on a regular base and this is very easy to do just setting up a call to
wp-cron.php. There are many ways to do that, let me show a couple of examples.
If and only if you setup a regular external call to
wp-cron.php (see below), you can even use the
that can improve the blog server overall loading and avoid overlapping job executions.
Check with a cron manager
You can see the internal scheduler status of your blog using, for example, Advanced Cron Manager. This really useful plugin adds and entry in the Tools menu of WP. It lists the active schedules with some information about their next execution. If the Newsletter schedule is correctly setup you should find something like:
newsletter schedule is not present, try to deactivate and reactivate the plugin.
This article from Kinsta deals with the cron problem when it created missing scheduled posts. Please note that while the scheduled posts do not require a timely and constantly cron trigger, Newsletter and other background service do.