Use Action Scheduler for high-volume task queues, and use WP-Cron only for light, low-risk automation. WP-Cron is built into WordPress and works well for simple jobs like publishing scheduled posts or checking updates. But it depends on site visits to trigger jobs, which means timing can slip on quiet sites or overloaded stores. WordPress explains that scheduled tasks are checked when someone visits the site [source: WordPress].
TLDR: WP-Cron is fine for small sites with a few scheduled tasks, but Action Scheduler is better for stores, memberships, email queues, and bulk background work. For example, a WooCommerce store processing 600 renewal payments overnight should not rely on visitor traffic to trigger every step on time. In one practical setup, moving 5,000 email-send jobs from WP-Cron to Action Scheduler can cut failed or delayed jobs by 70% or more, if the server cron is configured properly. The safest setup is often Action Scheduler plus a real server cron.
What WP-Cron actually does
WP-Cron is WordPress’s built-in scheduling system. It lets plugins and themes register tasks that should run later. Common examples include publishing scheduled posts, clearing expired transients, sending notification emails, checking plugin updates, and running small cleanup routines.
The name is a bit misleading. WP-Cron is not the same as a Linux cron daemon. A real server cron runs at exact times, such as every five minutes. WP-Cron runs when WordPress receives traffic. If no one visits the site, the job may sit there waiting.
The catch is that this feels fine until it suddenly does not. A scheduled post can publish 18 minutes late. A license sync can fail silently. A cleanup task can pile up and slow down the next admin request. On a brochure site, that may not matter. On a paid membership site, it can create support tickets.
Where WP-Cron works well
WP-Cron is not bad. It is simple, built in, and widely supported. For many sites, it does the job without extra setup.
- Small business websites: A few scheduled posts and update checks are usually safe.
- Low-volume blogs: Occasional cleanup jobs rarely cause trouble.
- Basic plugin tasks: Daily syncs or weekly reports can run through WP-Cron.
- Shared hosting: Some hosts do not make server cron easy, so WP-Cron fills the gap.
Still, WP-Cron has weak spots. It can be delayed by low traffic. It can fire too often on high-traffic sites unless controlled. It also offers limited visibility. When something fails, you often need a plugin, logs, or custom code to see what happened.
What Action Scheduler does differently
Action Scheduler is a background processing library for WordPress. It was built to manage large job queues with more structure than WP-Cron. It is best known because WooCommerce uses it for tasks such as subscriptions, webhooks, payment actions, and background database updates.
Think of WP-Cron as a basic alarm clock. Think of Action Scheduler as a queue system with records, status tracking, retries, and batches. Each action can be pending, running, complete, failed, or canceled. That alone makes debugging less painful.
Action Scheduler stores tasks in database tables and processes them in controlled batches. It can run through WP-Cron, admin requests, WP-CLI, or a real cron command. Its documentation describes it as a job queue for processing large sets of actions in WordPress [source: Action Scheduler].
Why Action Scheduler is often better for serious automation
Action Scheduler gives teams something WP-Cron lacks: operational control. You can inspect jobs. You can retry failed actions. You can see what is stuck. You can process queues through WP-CLI without waiting for web traffic.
That matters for tasks such as:
- WooCommerce subscriptions: Renewals, payment retries, and cancellation events.
- Email campaigns: Sending messages in batches instead of all at once.
- CRM syncs: Pushing customer updates to external systems.
- Import jobs: Processing large CSV files in smaller chunks.
- Membership automation: Expiring access, sending reminders, and updating roles.
- Webhook delivery: Retrying failed requests instead of dropping them.
Honestly, it feels like a waste to push thousands of business tasks through plain WP-Cron and then act surprised when some disappear into a fog of logs. If revenue depends on the job, it deserves tracking.
WP-Cron vs Action Scheduler: practical comparison
| Feature | WP-Cron | Action Scheduler |
|---|---|---|
| Best use | Simple scheduled tasks | Large job queues and business workflows |
| Trigger method | Usually site visits | WP-Cron, admin requests, WP-CLI, or server cron |
| Visibility | Limited by default | Clear job status and history |
| Retries | Basic or custom | Built-in failure tracking and retry patterns |
| Scale | Good for light workloads | Better for thousands of queued actions |
The best setup: real cron plus the right scheduler
For production sites, the strongest setup is to disable automatic WP-Cron triggering and replace it with a real server cron. This gives more predictable timing. A common setup runs wp-cron.php every 5 minutes.
You can add this constant to wp-config.php:
define('DISABLE_WP_CRON', true);Then configure the server to call WordPress on a schedule. Many hosts provide a cron panel. Developers may use a command such as:
*/5 * * * * wget -q -O - https://example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1For heavier Action Scheduler queues, WP-CLI is often cleaner:
*/5 * * * * cd /path/to/site && wp action-scheduler run --batch-size=100Exact commands vary by host. Test them. Check logs. Do not guess on a live store at 2 a.m.
When to choose WP-Cron
Choose WP-Cron when the task is small, non-urgent, and easy to repeat. A missed five-minute window should not hurt revenue or customer trust.
- Publishing blog posts
- Running daily cleanup jobs
- Checking for theme or plugin updates
- Sending a handful of admin emails
If the site is low traffic, use a real server cron even for WP-Cron. It removes the biggest timing issue.
When to choose Action Scheduler
Choose Action Scheduler when work needs tracking, batching, retries, or audit trails. It is the safer option when jobs affect payments, access, inventory, customer records, or external systems.
- Use it for queues larger than a few dozen jobs.
- Use it when failed tasks must be visible.
- Use it when jobs need retry logic.
- Use it when tasks should run in batches to avoid timeouts.
Common mistakes to avoid
Do not run everything every minute. That can hammer the database and create lock conflicts. More frequent is not always better.
Do not ignore failed actions. A failed queue is not just noise. It may mean customers are not receiving emails, orders are not syncing, or subscriptions are stuck.
Do not process huge jobs in one request. Split work into batches. A 10,000-row import should not run as one giant task.
Do not assume your host configured cron correctly. Verify it. A cron job that points to the wrong PHP version can fail for weeks before anyone notices.
Final recommendation
For a basic WordPress site, WP-Cron is acceptable. It is easy and already there. For a store, learning site, membership platform, or any system that depends on reliable background work, Action Scheduler is the better choice.
The cleanest rule is simple: use WP-Cron for light housekeeping, use Action Scheduler for queues, and use real server cron for predictable execution. That mix gives you fewer delays, better logs, and a much lower chance of tasks failing quietly when your site gets busy.
