Cart recovery depends on work that happens after the shopper leaves. Cart Rebound must detect inactive carts, queue an optional reminder, and clean up records according to configured retention windows. Those jobs need a healthy WordPress scheduling path.

Understand the two layers

WP-Cron is WordPress's trigger for time-based work. It checks for due events when the site receives a page load, so it does not behave like a continuously running system scheduler. On a quiet or access-restricted site, a task can run later than its nominal time.

Action Scheduler provides the traceable job queue used by WooCommerce and Cart Rebound. It stores individual actions and their status, arguments, schedule, and log. Action Scheduler still needs a runner, commonly initiated through WP-Cron. Seeing an action in the queue does not prove that the runner is processing it on time.

Know what healthy work looks like

Open WooCommerce > Status > Scheduled Actions, or Tools > Scheduled Actions where that menu is available. Search for Cart Rebound actions and review four conditions:

  • Pending: Future work is normal. An action that remains pending well after its scheduled time needs investigation.
  • In progress: Brief activity is normal. A long-running entry can indicate a stuck request or constrained server.
  • Complete: The callback finished. Confirm that its expected result also occurred.
  • Failed: Open the action log and record the error, timestamp, hook, and recurrence before retrying anything.

Also inspect WooCommerce > Status. The system report shows whether WordPress cron is disabled and summarizes Action Scheduler counts. This is useful evidence, but it does not replace checking whether recent actions actually complete.

Diagnose in the right order

When a cart does not become abandoned or an email does not leave the queue:

  1. Confirm that the cart has an email address, at least one item, and enough inactivity to pass the configured threshold.
  2. Confirm the site date, timezone, and Cart Rebound timing settings.
  3. Find the matching scheduled action and read its log.
  4. Check recent PHP and WooCommerce logs for the same time.
  5. Run WordPress Site Health and, when command-line access is available, use wp cron test to test cron spawning.
  6. Review loopback restrictions, password protection, maintenance mode, security rules, and host-level cron configuration.
  7. Fix the cause, then observe a fresh test cart through the full workflow.

Do not routinely delete failed actions before saving their logs. Do not repeatedly run every pending action on a production store. Another plugin may have placed time-sensitive work in the same queue.

Support low-traffic and busy stores

A low-traffic store may need the host's system scheduler to call WordPress cron at a consistent interval. If DISABLE_WP_CRON is enabled, a real replacement runner must exist. Otherwise due work will remain queued.

For a large queue or long-running actions, Action Scheduler documents a WP-CLI runner that avoids some web-request time and memory constraints. That is an infrastructure decision for the store owner or host. Start with measured queue data, use narrow hooks or groups where possible, and avoid increasing concurrency without understanding server capacity.

Make scheduling part of the operating routine described in the documentation. Check overdue and failed actions after deployment, after a host or security change, and during normal store reviews. Test both abandonment detection and delayed email delivery on staging. Keep the staging recovery checklist and email deliverability guide with the release procedure.

Reliable recovery is not a single cron setting. It is a queue that is scheduled, processed, logged, and reviewed.

Sources