How to run WordPress Crons reliably

The WordPress Cron (WP-Cron) lets your WordPress website execute background tasks. Typical background tasks include:

• keeping your users’ membership status in sync with payment gateway
• sending newsletters
• various background updates

There are three issues with WP-Cron:

1. WP-Cron does not run on a regular schedule, it can miss the scheduled jobs.
2. WP-Cron can also run too often and cause performance issues.
3. WP-Cron jobs can fail without notice.

Here’s how we fix these issues.

How to make WP-Cron reliable

WordPress (and PHP in general) does not have any robust way of running background jobs. WP-Cron simply depends on website visits, keeping track of last scheduled job execution date and time in the wp_options table and running the background jobs with HTTP calls.

Such execution of background jobs can become unreliable if:

• Your website is not getting visits around the clock consistently.
• You care about page load times and use a WordPress page cache plugin. WP-Cron will not run for cached hits.

So WP-Cron might just not be triggered often enough and can miss the schedule.

For this reason we trigger WP-Cron using the server operating system crontab for each website user every 5 minutes like this:

*/5 * * * * php public_html/wordpress/wp-cron.php >/dev/null 2>&1

Then we also add this to wp-config.php to make sure WordPress will no longer try to run WP-Cron on its own using HTTP:

define('DISABLE_WP_CRON', true);

How to avoid WP-Cron performance issues

As I mentioned above, sometimes there may not be frequent enough visits to your WordPress website to trigger the WP-Cron on a reliable schedule.

But the opposite can happen too: the WordPress Cron can even trigger too often. I was shocked to find that on one of our websites WP-Cron would run even 4 times per minute!

Here’s an excerpt from the web server access logs – the columns are time, request, response code and runtime. So we can see wp-cron.php not doing much, but doing it very often, even 4 times at 07:44:

[13/Jan/2026:07:39:08 +0000] "POST /wp-cron.php HTTP/1.1" 200 0.131
[13/Jan/2026:07:39:46 +0000] "POST /wp-cron.php HTTP/1.1" 200 0.001
[13/Jan/2026:07:40:04 +0000] "POST /wp-cron.php HTTP/1.1" 200 0.001
[13/Jan/2026:07:40:05 +0000] "POST /wp-cron.php HTTP/1.1" 200 0.001
[13/Jan/2026:07:40:45 +0000] "POST /wp-cron.php HTTP/1.1" 200 0.001
[13/Jan/2026:07:41:04 +0000] "POST /wp-cron.php HTTP/1.1" 200 0.004
[13/Jan/2026:07:41:05 +0000] "POST /wp-cron.php HTTP/1.1" 200 0.001
[13/Jan/2026:07:41:45 +0000] "POST /wp-cron.php HTTP/1.1" 200 0.001
[13/Jan/2026:07:42:06 +0000] "POST /wp-cron.php HTTP/1.1" 200 0.001
[13/Jan/2026:07:42:44 +0000] "POST /wp-cron.php HTTP/1.1" 200 0.001
[13/Jan/2026:07:43:04 +0000] "POST /wp-cron.php HTTP/1.1" 200 0.002
[13/Jan/2026:07:43:06 +0000] "POST /wp-cron.php HTTP/1.1" 200 0.001
[13/Jan/2026:07:43:45 +0000] "POST /wp-cron.php HTTP/1.1" 200 0.002
[13/Jan/2026:07:44:04 +0000] "POST /wp-cron.php HTTP/1.1" 200 0.001
[13/Jan/2026:07:44:05 +0000] "POST /wp-cron.php HTTP/1.1" 200 0.001
[13/Jan/2026:07:44:15 +0000] "POST /wp-cron.php HTTP/1.1" 200 0.002
[13/Jan/2026:07:44:44 +0000] "POST /wp-cron.php HTTP/1.1" 200 0.002
[13/Jan/2026:07:45:04 +0000] "POST /wp-cron.php HTTP/1.1" 200 0.001

Note: The query strings like ?doing_wp_cron=1768290304.8027579784393310546875 were omitted to improve readability.

The only time it actually did something was at 07:39:08 and it took 131 milliseconds to complete.

This situation improved once we just setup the crontab for all websites. Now the WordPress Cron jobs run in predictable intervals and do not create extra server load by running too often.

How to monitor WP-Cron failures

By default WP-Cron runs requests to /wp-cron.php using an HTTP request. So if there’s a PHP fatal error, it will be logged in your PHP error logs.

So while it’s not impossible to see if the WP-Cron has failed, it’s certainly not easy. An important part of your WordPress plugins’ background processing might be failing and you won’t know.

The technology to monitor our cron jobs is called FV Cron Status Page.

We simply send the output of our cron jobs to it using HTTP and then get alerted about errors using one of:

• Email
• Basecamp 3 Campfire
• Rocket.chat
• Teamwork PM

It does mean each cron job needs some adjustments though:

*/5 * * * * php public_html/wordpress/wp-cron.php 2>&1 | curl -X POST --data-urlencode "data=$(cat)" 'https://crons.foliovision.com/?name=wp_cron'

But we are on top of our cron jobs and know about any failures immediately. If the WP-Cron job fails with a PHP error, we get notified about the error.

FV Cron Status Page can be found on Github.

Martin Viceník

Martin graduated as an engineer in Computer Science from Slovak Technical University in Bratislava. He grew up in Liptovský Mikuláš in northern Slovakia next to the beautiful Tatra mountains. He is the developer behind our FV Player.