r/woocommerce

We’re currently troubleshooting load spikes on a fairly large WooCommerce shop.

What we see in the logs:

• several thousand wp-cron.php requests per day
• many dynamic requests to admin-ajax.php, cart and Woo AJAX
• a noticeable number of 499 responses under load
• Action Scheduler itself is working, and the number of scheduled daily actions is not huge
• around 39 scheduled actions run daily, roughly 15 of them are CTX Feed related
• around 1,370 Action Scheduler jobs completed successfully yesterday
• the Action Scheduler queue runner itself also showed many aborted requests in the access log

Cloudflare is now in front of the site and already reduces a lot of static traffic, but wp-cron.php, admin-ajax.php and /cart/ are still among the busiest uncached dynamic paths.

So I’m considering disabling WP-Cron with:

define('DISABLE_WP_CRON', true);

and replacing it with a real server-side cron job, probably every 5–15 minutes.

For those running larger WooCommerce stores:

Did switching from WP-Cron to a real server cron noticeably reduce server load or 499/timeout issues for you?

Or did it mainly make cron execution more predictable without changing overall resource usage much?

I’m especially interested in real-world experience from stores with substantial bot/crawler traffic and lots of dynamic WooCommerce requests.

Side business out of Austin TX, custom gift boxes on Woo, been at it about four years. Peak season (Oct–Dec) we float around 650–700 orders a month. Still on the same managed Woo plan from when I was doing 40 orders a month, ~$45/mo, shared CPU with a hard throttle when usage spikes.

Checkout randomly spins, admin order list takes forever, and Tools → Scheduled Actions shows hundreds of pending hooks after a busy weekend. PageSpeed on product pages still looks fine so my brain keeps blaming background junk instead of the storefront.

Already tried Cloudflare in front with cart/checkout bypass rules, DISABLE_WP_CRON plus a real cron every 10 min on the host panel, and clearing failed actions twice. Also disabled a social feed sync plugin that was enqueueing retries.

Host support keeps pointing at the plan tier. A dev friend keeps saying move to a small VPS so cron and MySQL arent fighting neighbors. I cant tell if Im paying for guilt or if shared is genuinely the ceiling at this order volume.

For stores in that awkward middle (not enterprise, not hobby): when checkout got flaky, did fixing the queue + real cron calm it down on shared, or did you only get relief after you left shared entirely? What was the thing that finally made the cause obvious in hindsight?

Has anyone used Helcim as their payment processor? They seem to be much cheaper than Stripe. 2.1% vs 2.9%.

But I don't know about them if they would hold funds and if they can be trusted?

Hi

can anyone recommend a good fast filter system for woocommerce products.

Thanks

I’m building a WooCommerce store for a client based in Switzerland, selling clothing and fashion jewellery mainly in Switzerland and nearby Europe.

This is a store designed for employees of one company to use, as guests (no login required was the initial request, have some flexibility there). All products are stocked.

There are 7 single and 3 variable products that need to be purchasable individually, partially bundled, and fully bundled, based on who's buying, or more likely, from what category they're provided access to.

CAT A: all products individually, plus the 7 single products as a bundle with preset qty for each.

CAT B: all 7 single products as a bundle without showing the individual items, and force buyer to select one variant from each of the variable products before checking out.

Apparently it's not possible to include a bundle within another bundle, so that limits how I can present these options in CAT B.

It appears the combination of a bundles plugin and forced sell plugin might do the trick for CAT B, but I believe that will unnecessarily impact the products in CAT A, as there does not seem to be in conditional logic in those types of plugins.

So aside from custom PHP to enforce conditional logic per category, can you suggest an alternative approach?

One possible workaround is adding a "shared stock" solution, so that we can create clones that share a common stock count, and present the clones in CAT A using a separate bundle. This way the force sell plugin only impacts the original products not the clones. However this complicates our front end stock management tool, for reasons too complicated to explain here.

Lastly, it's possible to introduce user roles into this, for CAT A buyers, if doing so would better allow for conditional overrides of the bundles/force sell combination.

This is specific to PayPal. We are thinking about switching payment action from capture to just authorize. My question is if anyone here has made that switch and what was the impact to subscription renewals? Did it cause issues with billing agreements and/or token validation? Other gotchase?