Troubleshooting Issues with Action Scheduler and WP-Cron

WordPress uses a system called WP-Cron to schedule repeated background tasks. As of Paid Memberships Pro v3.5+, background tasks now use Action Scheduler instead of WP-Crons.

While core PMPro processes have moved to Action Scheduler, older versions of the core plugin, Add Ons and legacy features still rely on WP-Cron. This guide will help you understand both systems, identify which one is running your task, and troubleshoot issues in each.

An Overview of Action Scheduler

Action Scheduler is a background job runner designed to queue tasks (called actions) in a more reliable, trackable way than WP-Cron. Instead of relying on page visits to trigger tasks, it uses its own queue system to execute jobs in batches. Paid Memberships Pro uses the queue to process larger tasks by breaking them down into smaller ones that Action Scheduler can process.

Key benefits include:

• Improved reliability: Jobs aren’t missed due to low traffic or caching.
• Better performance: Large tasks are split into smaller actions, reducing timeouts and using less resources.
• Detailed logs: You can review when an action was created, started, completed, or failed.
• Granular control:  Actions can be retried or run manually without waiting for the next scheduled run.

In PMPro, Action Scheduler handles core background processes, including expiration checks, reminder emails, and maintenance routines.

An Overview of the WP-Cron System

Every time WordPress is loaded, WP-Cron will check if there are any scheduled tasks. If there are, those tasks are kicked off and run during that page load. There are a few issues unavoidable issues with this setup:

1. WP-Cron relies on traffic to your website. If no one is accessing your website in the early morning when PMPro wants to expire memberships, that task may not run on time or at all.
2. WordPress is not loaded when your site serves a page from cache. While caching is a good idea to balance the load on your server, it means that only users accessing the WordPress dashboard or a non-cached page on your site will kick off WP-Cron.
3. If your site is not running WP-Cron regularly, tasks can back up. This could lead to long load times for users when their one visit happened to trigger WP-Cron or timeouts where scheduled tasks never finish at all.

How to Tell Which System Your Site Is Using

The easiest way to determine whether your site is running tasks through Action Scheduler or WP-Cron is to check your WordPress dashboard.

1. Check your PMPro version: If you are using PMPro v3.5 or newer, core background processes (expirations, reminders, maintenance tasks) will use Action Scheduler. If you are using an older version of PMPro or our Add Ons, those tasks may still rely on WP-Cron.
2. Look in the Tools Menu: Navigate to Tools > Action Scheduler. If you see this option, then Action Scheduler is active on your site. If the option is missing and you’re running PMPro v3.5 or newer another plugin may be interfering with Action Scheduler.

Troubleshooting Action Scheduler

If you notice issues with Action Scheduler, such as the menu item not available within the Tools section, its logs filling up for unknown reasons, there are a couple of actions you can take to diagnose the issue.

Unavailable in the Tools Menu

Paid Memberships Pro does not load its own bundled version of Action Scheduler if another plugin already loads it. To determine if another plugin is loading Action Scheduler, navigate to Tools > Site Health with your WordPress admin. 

The Paid Memberships Pro section of your Site Health will provide information about what plugin is loading Action Scheduler. 

Corrupt Tables

In rare cases, the tables that Action Scheduler relies on may become corrupt. This can happen when an older version of Action Scheduler was loaded at some point in the past and the newer version couldn’t migrate the tables correctly. A clear indicator of this is that Action Scheduler logs fill up with a large amount of failed events and messages. To confirm this is happening, check your database or ask your host.

The fastest way to resolve this is to drop (remove) the tables that Action Scheduler creates, and recreate them. The tables to remove are:

• {wp}_actionscheduler_actions
• {wp}_actionscheduler_logs
• {wp}_actionscheduler_claims
• {wp}_actionscheduler_groups

After removing these tables, visit the Scheduled Actions admin page (Tools > Scheduled Actions) and Action Scheduler will reload its missing tables.

Troubleshooting WP-Crons

Using the WP Crontrol Plugin

One way to debug issues with WP-Cron is the WP Crontrol Plugin by John Blackbourn & ‘crontributors’. This free plugin will add a page to your dashboard under Tools > Cron Events. This page will contain a table of all scheduled cron events for your WordPress site.

Browse through the list of cron events and look for the ones created by Paid Memberships Pro:

• pmpro_cron_expire_memberships
• pmpro_cron_expiration_warnings
• pmpro_cron_credit_card_expiring_warnings
• pmpro_cron_admin_activity_email
• pmpro_cron_recurring_payment_reminders

If these events are not on the list, then you can force PMPro to regenerate them by deactivating and reactivating the core PMPro plugin.

Some of the Paid Memberships Pro Add Ons also add cron events. We prefix all of our cron events with the term pmpro. For example, the Series: Drip-Feed Add On adds a cron event titled pmpros_check_for_new_content.

If the cron events are in the list, you can click the “Run Now” link to force the cron event to run. To test if expirations are working, you could set your own membership to expire on yesterday’s date. Then run the pmpro_cron_expire_memberships event and see if your membership is expired and if you get the expiration email.

If your membership is expired, but you don’t receive the email, see our email troubleshooting guide for help with that.

If the cron event runs fine when you run it through the Cron Events page, but doesn’t seem to trigger on it’s own at night, then you will want to read the next section on setting up a more reliable cron service.

Adjusting Cron Schedules at The Server Level

WP-Cron only runs when a user visits a non-cached page on your WordPress site. For this reason, some sites may decide to set up a server-level rule that triggers WP-Cron to run more often, every 5 minutes or so.

Some hosts have limits on how frequent cron job intervals may run. If you have a good WordPress host, like we recommend here, your host may already have something like this set up. If not, a support request like the following should be enough for them to set up your server to run WP-Cron every 5 minutes.

First, Ask Your Host to Run Crons at the Server Level

Make sure to swap in your own domain name in the URL above. Make sure it ends with /wp-cron.php?doing_wp_cron.

Also make sure that URL is excluded from any caching plugin or system you have running on the site.

Then, Disable the Default WP-Cron Service

Once the server-based cron is running, you can disable the regular WP-Cron checks that happen on random page loads by adding the following to your wp-config.php file:

define('DISABLE_WP_CRON', true);

Adding the above to your wp-config.php file will ensure that random users on your site do not kick off cron events that would slow down their browsing. Since your server is doing this every 5 minutes now, you won’t need WP-Cron to run on random page loads anymore.

If your host cannot or will not set up the cron job for you, ask them for information on how you can do it yourself. The directions will be different depending on the type of server and control panel software involved. You can find more information about how to set up a server side cron job in the WP developer documentation here and this useful blog post on WP-Cron by Tom McFarlin.

The cron job that you set up, should look something like this in the file:

*/5 * * * * wget -q -O - http://yourdomain.com/wp-cron.php?doing_wp_cron

Broken down, this line will tell cron to run every 5 minutes, every hour, every day, every month, every day of the week. The wget command line program is run to load your website. The -q parameter says to do so “quietly” with no output. The -O - parameter is telling wget to not save the webpage locally.

Another option is to use a paid service like SetCronJob. SetCronJob will basically set up a cron job on their own servers to ping your site every so often. This works exactly the same as setting a cron on your server itself, but could be less complicated for some users on some hosts.

We also recommend using a service like Cron-job.org  It allows you to set up as many cronjobs as you like.

Wrapping Up

Whether your site is using Action Scheduler or WP-Cron depends on your PMPro version, installed Add Ons, and hosting environment. Action Scheduler offers a more reliable and transparent way to handle recurring tasks, but WP-Cron may still be in play for legacy setups or custom code.

By checking your tools menu, Site Health, and scheduled events, you can confirm which system your site is using and apply the right troubleshooting steps. If you’ve followed these guidelines and are still experiencing issues, don’t hesitate to contact our support team for additional help.