Checkout slowdowns.

  • Resolved Imagevineesh1994

    (@vineesh1994)


    1 month, 3 weeks ago

    Hi WooCommerce Team,

    We're experiencing severe checkout slowdowns when multiple orders come in simultaneously (5+ orders at once). During peak times, checkout takes 30+ seconds and sometimes fails completely.

    The Problem:
    Our PHP slow logs show ActionScheduler_AsyncRequest_QueueRunner.php appears 1,116+ times, with sleep() calls at line 53 that block PHP-FPM workers. Each checkout triggers async processing, and during concurrent orders, all PHP workers get stuck, creating a queue buildup.

    PHP Slow Log Excerpt:

    [0x00007f3bb20143e0] sleep() /wp-content/plugins/woocommerce/packages/action-scheduler/classes/ActionScheduler_AsyncRequest_QueueRunner.php:53
    [0x00007f3bb2014370] handle() /wp-content/plugins/woocommerce/includes/libraries/wp-async-request.php:147

    Full Stack Trace from our logs:

    [16-Jan-2026 14:00:45] script_filename = /home/…/public_html/index.php
    [0x00007f3bb20143e0] sleep() /…/ActionScheduler_AsyncRequest_QueueRunner.php:53
    [0x00007f3bb2014370] handle() /…/wp-async-request.php:147
    [0x00007f3bb2014300] maybe_handle() /…/class-wp-hook.php:324
    … leading back to checkout process

    Impact:
    This is severely affecting sales during peak hours when multiple customers try to checkout simultaneously.

    Guidance on optimizing Action Scheduler for concurrent order processing, or a recommended configuration for stores experiencing high simultaneous checkout volume.

    Any help would be greatly appreciated as this is causing revenue loss.

    Thank you,
    Marc.

    The page I need help with: [log in to see the link]

Viewing 14 replies - 1 through 14 (of 14 total)
  • Plugin Support Imageshahzeen(woo-hc)

    (@shahzeenfarooq)

    1 month, 3 weeks ago

    Hi there!

    Thanks for the detailed report and for sharing the slow log snippet, that is very helpful. From your description, it looks like the checkout slowdown is linked to how Action Scheduler is processing queued tasks under high concurrency rather than a single specific error.​

    To help narrow this down and recommend concrete changes, could you please share a bit more information:

    • System Status Report which you can find via WooCommerce > Status
    • Fatal error logs (if any) under WooCommerce > Status > Logs.

    Please use https://pastebin.com/ or https://gist.github.com/ and share a link to that paste in reply here. Once we have more information, we’ll be able to assist you further.

    Thread Starter Imagevineesh1994

    (@vineesh1994)

    1 month, 3 weeks ago

    I have shared the system report link in your slack account. please check it out.

    Plugin Support Imageshahzeen(woo-hc)

    (@shahzeenfarooq)

    1 month, 3 weeks ago

    Hi there!

    Thanks for the update. Could you please share the WooCommerce System Status report directly here in this thread instead?

    Please use https://pastebin.com/ or https://gist.github.com/ and share a link to that paste in reply here. At the moment, I don’t have access to Slack accounts or shared links there, so I’m unable to view the report you mentioned. Once you paste the system status report here, I’ll be happy to review it and help you further.

    Thread Starter Imagevineesh1994

    (@vineesh1994)

    1 month, 3 weeks ago

    https://gist.github.com/vineeshw1994/cdb5f545b1f2a85189b7b349ef79b329

    Plugin Support Imageshahzeen(woo-hc)

    (@shahzeenfarooq)

    1 month, 3 weeks ago

    Hi there,

    I’ve reviewed the system status report and noticed that your WordPress, WooCommerce, and the active theme are currently out of date. I also see that your theme is overriding several WooCommerce templates, which can sometimes lead to unexpected behavior or performance issues.

    To help us investigate this further, could you please create a staging site and then:

    1. Update WordPress and WooCommerce to their latest versions.
    2. Update the theme and ensure all overridden WooCommerce templates are also updated and compatible with the current WooCommerce version.

    If the issue persists after updating, please run a conflict test on the staging site by:

    • Deactivating all plugins except WooCommerce
    • Temporarily switching to a default theme, such as Twenty Twenty-Five

    This will help us determine whether the issue is being caused by a plugin or theme conflict.

    You can follow this guide for step-by-step instructions on running a conflict test:
    https://woocommerce.com/document/how-to-test-for-conflicts/#how-to-do-a-conflict-test

    Once you’ve completed these steps, let us know what you find and we’ll be happy to continue assisting you.

    Thread Starter Imagevineesh1994

    (@vineesh1994)

    1 month, 2 weeks ago

    Thank you for your guidance.

    We’ve now completed the requested steps on a staging environment:

    WordPress and WooCommerce have both been updated to their latest versions.

    The active theme was reviewed; there are no newer theme updates currently available.

    The theme does include a number of overridden WooCommerce templates which are flagged as outdated after the WooCommerce update.

    After completing the updates, we carried out functional testing across key flows, including product pages, cart, checkout, order placement, and order management in the admin area so the functionality is working. But, we did not any changes, the performance and everything still the same and the problem is not solved yet.

    Given that the site is functioning correctly, we have not yet updated the overridden WooCommerce templates, as these are legacy customizations and updating them wholesale could introduce regressions. At this stage, the outdated template notices do not appear to be contributing to the reported issue.

    Please let us know if you’d recommend proceeding with a plugin/theme conflict test despite the absence of issues, or if there are specific templates or logs you’d like us to review next.

    Thanks again for your assistance.

    System Report Github Link : https://gist.github.com/vineeshw1994/58c19b2763ce1decc5e3be1da1bdef59

    Plugin Support Imageshahzeen(woo-hc)

    (@shahzeenfarooq)

    1 month, 2 weeks ago

    Hi there!

    Thank you for the detailed follow-up and for thoroughly testing this on a staging environment we appreciate the effort, especially given the impact this is having during peak sales periods.

    Based on your original report and the slow log entries you shared, this behavior is related to how Action Scheduler processes background tasks during checkout, particularly under concurrent load. While Action Scheduler is designed to run asynchronously, WooCommerce itself does not provide configuration options to control PHP-FPM worker usage, sleep behavior, or concurrency limits at the server level. A few important clarifications

    • When multiple orders are placed simultaneously, performance issues typically surface due to server-level limits (PHP-FPM workers, CPU, memory, process handling), rather than a WooCommerce bug alone.
    • WooCommerce core does not currently include built-in performance tuning controls for Action Scheduler under high concurrency.

    Recommended next steps:

    1. Still run a plugin/theme conflict test on staging
      Even if the site appears functional, third-party plugins can add additional scheduled actions during checkout, significantly increasing queue pressure.
      • Deactivate all plugins except WooCommerce
      • Switch temporarily to Storefront
      • Test concurrent checkouts again
    2. Review scheduled actions
      Please check:
      • WooCommerce → Status → Scheduled Actions
      • Queue size, frequency, and any failed or recurring actions triggered at checkout time

    If the issue persists after a conflict test, it would indicate that the bottleneck is likely related to server configuration or scaling, In that case, your hosting provider would be best positioned to advise on PHP-FPM worker limits, process handling, and concurrency optimization.

    Please let us know the outcome of the conflict test and what you see in the Scheduled Actions queue. That will help determine the most appropriate next step.

    Thread Starter Imagevineesh1994

    (@vineesh1994)

    1 month, 2 weeks ago

    Our WooCommerce site is hosted on Cloudways. I’ve initially contacted the Cloudways support team regarding the performance concerns, and they reviewed the server configuration. As part of that process, they increased the PHP workers and confirmed that CPU, memory, and process limits are already set to their recommended maximums for our server.

    Cloudways advised that the server-side configuration does not appear to be the bottleneck and suggested reaching out to the plugin/application support team for further investigation.

    I’m now begun testing the recommended steps on a staging environment and will continue with the remaining checks. We’ll update you with our findings once testing is complete.

    Thanks for your support.

    Plugin Support ImageLovingBro (woo-hc)

    (@lovingbro)

    1 month, 2 weeks ago

    Hi @vineesh1994,

    Thanks for the update and for keeping us in the loop. It is good to see that you are actively testing the remaining steps on staging, especially after confirming the server side adjustments with Cloudways. Please feel free to let us know how the conflict testing and scheduled action checks go, and share any observations you notice during those tests so we can continue guiding you from there.

    Thread Starter Imagevineesh1994

    (@vineesh1994)

    1 month, 2 weeks ago

    We are currently performing all testing on our staging environment. At this stage, we have not deactivated plugins, as the active plugins are essential to the checkout and order processing flow even on staging. However, we did test concurrent checkout requests with the existing setup.

    During testing, orders are successfully created and processed, but under concurrent load the processing time increases noticeably.

    We also reviewed WooCommerce → Status → Scheduled Actions for the latest concurrent orders. The primary actions created at checkout time are:

    • wc-admin_import_orders (non-repeating, created per order)
    • woocommerce_deliver_webhook_async (multiple webhooks per order)

    These actions are being queued as Pending and are not failing, which indicates that Action Scheduler is functioning as expected. The slowdown observed under concurrency appears to be related to queue pressure and available server resources rather than order creation failures.

    We understand the importance of isolating third-party impact and will proceed with a plugin/theme conflict test on the staging environment (WooCommerce only + Storefront) to confirm whether the behavior persists without third-party plugins.

    Please let us know if there is any additional data you would like us to collect during the staging test.

    These are the logs of WooCommerce → Status → Scheduled Actions:

    wc-admin_import_orders
    Run | Cancel
    Pending
    0 => 1017023
    wc-admin-data Non-repeating 2026-01-23 11:53:13 +0000
    (14 seconds ago)
    2026-01-23 11:53:08 +0000
    action created

    wc-admin_import_orders
    Run | Cancel
    Pending
    0 => 1017024
    wc-admin-data Non-repeating 2026-01-23 11:53:13 +0000
    (14 seconds ago)
    2026-01-23 11:53:08 +0000
    action created

    wc-admin_import_orders
    Run | Cancel
    Pending
    0 => 1017025
    wc-admin-data Non-repeating 2026-01-23 11:53:17 +0000
    (10 seconds ago)
    2026-01-23 11:53:12 +0000
    action created

    woocommerce_deliver_webhook_async
    Run | Cancel
    Pending
    'webhook_id' => 12
    'arg' => 1017023
    woocommerce-webhooks Non-repeating 2026-01-23 11:53:18 +0000
    (9 seconds ago)
    2026-01-23 11:53:18 +0000
    action created

    woocommerce_deliver_webhook_async
    Run | Cancel
    Pending
    'webhook_id' => 13
    'arg' => 1017023
    woocommerce-webhooks Non-repeating 2026-01-23 11:53:18 +0000
    (9 seconds ago)
    2026-01-23 11:53:18 +0000
    action created

    woocommerce_deliver_webhook_async
    Run | Cancel
    Pending
    'webhook_id' => 12
    'arg' => 1017022
    woocommerce-webhooks Non-repeating 2026-01-23 11:53:18 +0000
    (9 seconds ago)
    2026-01-23 11:53:18 +0000
    action created

    woocommerce_deliver_webhook_async
    Run | Cancel
    Pending
    'webhook_id' => 13
    'arg' => 1017022
    woocommerce-webhooks Non-repeating 2026-01-23 11:53:18 +0000
    (9 seconds ago)
    2026-01-23 11:53:18 +0000
    action created

    woocommerce_deliver_webhook_async
    Run | Cancel
    Pending
    'webhook_id' => 12
    'arg' => 1017024
    woocommerce-webhooks Non-repeating 2026-01-23 11:53:18 +0000
    (9 seconds ago)
    2026-01-23 11:53:18 +0000
    action created

    woocommerce_deliver_webhook_async
    Run | Cancel
    Pending
    'webhook_id' => 13
    'arg' => 1017024
    woocommerce-webhooks Non-repeating 2026-01-23 11:53:18 +0000
    (9 seconds ago)
    2026-01-23 11:53:18 +0000
    action created

    woocommerce_deliver_webhook_async
    Run | Cancel
    Pending
    'webhook_id' => 12
    'arg' => 1017025
    woocommerce-webhooks Non-repeating 2026-01-23 11:53:22 +0000
    (5 seconds ago)
    2026-01-23 11:53:22 +0000
    action created
    • This reply was modified 1 month, 2 weeks ago by Imagevineesh1994.
    Plugin Support Imageshahzeen(woo-hc)

    (@shahzeenfarooq)

    1 month, 2 weeks ago

    Hi there!

    Thank you for the detailed explanation that’s excellent testing and very helpful context.

    Based on what you’ve shared, your assessment looks correct. Since orders are being created and processed successfully and the scheduled actions are queued as Pending (not failing), this does indicate that Action Scheduler itself is functioning as expected. Under concurrent load, increased processing time is commonly related to queue pressure, PHP workers, database performance, or overall server resources, rather than a WooCommerce order-creation issue.

    Your plan to proceed with a conflict test on staging using WooCommerce only + Storefront is the right next step. If the behavior persists in that minimal setup, it would strongly suggest a server-level or infrastructure constraint rather than a plugin or theme issue. If the issue does not occur in the minimal setup, we can then narrow it down by re-enabling plugins incrementally.

    Let us know what you find.

    Thread Starter Imagevineesh1994

    (@vineesh1994)

    1 month, 2 weeks ago

    Hi There,

    We reviewed the Scheduled Actions logs during both normal traffic and high-concurrency checkout scenarios and wanted to share our findings.

    During normal traffic (no active orders), we only see expected low-frequency maintenance actions such as WPForms tasks, WP Mail SMTP notifications, and WooCommerce cleanup jobs. These actions are scheduled and not triggered by checkout activity.

    However, during concurrent checkouts, we consistently see a spike in WooCommerce-generated background tasks, specifically:

    • wc-admin_import_orders (WooCommerce Admin / Analytics)
    • wc_delete_related_product_transients_async (WooCommerce core cache cleanup)

    These actions are created once per order and, under high concurrency, are scheduled multiple times within the same second. This causes a noticeable increase in the Action Scheduler queue size and correlates directly with slower order processing.

    At this point, we do not see evidence of third-party plugins adding checkout-time scheduled actions. The queue pressure appears to be coming from WooCommerce core and WooCommerce Admin tasks triggered during order creation.

    Based on this, we believe the performance impact is related to how these WooCommerce background jobs scale under concurrent checkout load, rather than a plugin conflict.

    Please let us know if you’d recommend:

    • Disabling or deferring WooCommerce Admin analytics imports, or
    • Any best practices for handling these background tasks under high concurrency.

    Thanks for your guidance.

    These are the logs :

    wc_delete_related_product_transients_async Run | Cancel Pending ‘post_id’ => 1016961 wc_delete_related_product_transients_group Non-repeating 2026-01-26 12:27:08 +0000 (Now!) 2026-01-26 12:27:08 +0000 action created

    wc_delete_related_product_transients_async Run | Cancel Pending ‘post_id’ => 1016961 wc_delete_related_product_transients_group Non-repeating 2026-01-26 12:27:08 +0000 (Now!) 2026-01-26 12:27:08 +0000 action created

    wpforms_process_forms_locator_scan Run | Cancel Pending ‘tasks_meta_id’ => 1 wpforms Every 1 day 2026-01-27 04:18:29 +0000 (15 hours 51 minutes) 2026-01-26 04:18:29 +0000 action created woocommerce_cleanup_draft_orders Run | Cancel Pending Every 1 day 2026-01-27 04:18:29 +0000 (15 hours 51 minutes) 2026-01-26 04:18:29 +0000 action created wp_mail_smtp_admin_notifications_update Run | Cancel Pending 0 => 256 wp_mail_smtp Every 1 day 2026-01-27 04:18:29 +0000 (15 hours 51 minutes) 2026-01-26 04:18:29 +0000 action created wpforms_process_purge_spam Run | Cancel Pending ‘tasks_meta_id’ => 2209 wpforms Every 1 day 2026-01-27 04:18:29 +0000 (15 hours 51 minutes) 2026-01-26 04:18:29 +0000 action created

    wpforms_email_summaries_fetch_info_blocks Run | Cancel wc-admin_import_orders Run | Cancel Pending 0 => 1017171 wc-admin-data Non-repeating 2026-01-26 12:27:07 +0000 (39 seconds ago) 2026-01-26 12:27:02 +0000 action created wc-admin_import_orders Run | Cancel Pending 0 => 1017172 wc-admin-data Non-repeating 2026-01-26 12:27:07 +0000 (39 seconds ago) 2026-01-26 12:27:02 +0000 action created

    wc-admin_import_orders Run | Cancel Pending 0 => 1017173 wc-admin-data Non-repeating 2026-01-26 12:27:07 +0000 (39 seconds ago) 2026-01-26 12:27:02 +0000 action created wc-admin_import_orders Run | Cancel Pending 0 => 1017174 wc-admin-data Non-repeating 2026-01-26 12:27:07 +0000 (39 seconds ago) 2026-01-26 12:27:02 +0000 action created

    Plugin Support ImageSai (woo-hc)

    (@saivutukuru)

    1 month, 2 weeks ago

    Hi @vineesh1994,

    Thank you for the detailed testing and for sharing the additional Scheduled Actions logs. That’s very helpful.

    Based on everything you’ve outlined, your analysis is correct. The background jobs you’re seeing (wc-admin_import_orders and wc_delete_related_product_transients_async) are WooCommerce core actions that are intentionally triggered during order creation. Under high-concurrency checkout scenarios, it’s expected that these actions are created in quick succession, which can increase Action Scheduler queue pressure and lead to longer processing times when server resources are contended.

    At this time, WooCommerce does not provide a supported way to change the execution behavior, rate, or concurrency limits of Action Scheduler tasks at the application level, nor do we offer a setting to throttle or batch these core background jobs. Because of this, increasing rate limits or modifying how these actions are processed is outside the scope of WooCommerce core support.

    A few important clarifications and recommendations:

    • Disabling WooCommerce Admin analytics may reduce some wc-admin_import_orders activity, but this is optional and primarily affects reporting/analytics. It is not guaranteed to resolve checkout slowdowns under concurrency.
    • Action Scheduler itself is functioning as expected, actions are queued and processed without failures.
    • When performance issues occur only under simultaneous checkouts, this typically points to infrastructure-level constraints such as PHP worker availability, database performance, or how background jobs are executed by the hosting environment.

    Since you’ve already confirmed with Cloudways that PHP workers and resources are at recommended limits, the most impactful next steps would be:

    • Continuing to work with your host on background job handling, database performance, and PHP-FPM process behavior under concurrency.
    • Verifying whether checkout-triggered webhooks can be reduced or consolidated, as each webhook creates additional scheduled actions.
    • Considering architectural optimizations (for example, offloading webhooks or analytics processing) if high simultaneous order volume is a regular use case.

    At this stage, there’s no indication of a bug in WooCommerce core, and the behavior observed aligns with how background processing is currently designed to work. We’re happy to continue reviewing findings from your minimal-setup tests, but changes to rate limits or scheduler internals would need to be handled at the hosting or infrastructure level.

    Please let us know if you have any further results to share.

    Plugin Support Imagethelmachido a11n

    (@thelmachido)

    1 month, 1 week ago

    It’s been a while since we heard back from you for this reason we are closing this thread. 

    If WooCommerce has been useful for your store and you appreciate the support you’ve received, we’d truly appreciate it if you could leave us a quick review here: 

     https://wordpress.org/support/plugin/woocommerce/reviews/#new-post

    Feel free to open a new forum topic if you run into any other problem. 

Viewing 14 replies - 1 through 14 (of 14 total)

You must be logged in to reply to this topic.