Doodla Website Performance — Cron Job Overload
Overview
The Doodla WooCommerce site experienced persistent 502/504 gateway errors and general slowness traced to server overload from excessive background processes (WordPress cron jobs). Troubleshooting was conducted by Mark Hope in coordination with WP Engine support during November 2025.
Related client: [1]
Symptoms
- Frequent 502 and 504 gateway errors across the site, including on the checkout page
- General page load slowness (visible on shop, cart, and checkout flows)
- Errors appeared intermittently, affecting real customer orders
Root Cause
The primary culprit was WordPress cron job overload — a large number of background scheduled tasks running concurrently and exhausting server resources. Contributing factors included:
- WP Rocket's "Remove Unused CSS" queue runner — identified via AI-assisted analysis (Claude) of an exported cron job list as the most likely high-load process
- WooCommerce HubSpot Sync plugin — polling every 5 minutes, creating frequent background load even when HubSpot integration wasn't actively needed for the site
- Imagify image optimization plugin — running alongside the already-active Smush plugin, causing redundant and conflicting optimization processes
- 13,000+ scheduled actions in the Action Scheduler queue, with 31 pending at time of review
- Possible database autoloader bloat (flagged for follow-up investigation via console)
A secondary contributing issue was Cloudflare Turnstile, which was blocking customers from completing checkout — resolved separately (see below).
Troubleshooting Steps Taken
1. Replaced Cloudflare Turnstile with WooCommerce V3 Captcha
Cloudflare Turnstile was preventing order completion. It was removed and replaced with the WooCommerce reCAPTCHA v3 plugin, which runs silently in the background and only challenges users it suspects are bots — invisible to legitimate customers.
2. AI-Assisted Cron Job Analysis
The WordPress cron job list was exported, converted to PDF, and submitted to Claude for analysis. Claude identified WP Rocket's Remove Unused CSS Queue Runner as the most likely performance bottleneck and recommended:
- Disabling the Remove Unused CSS feature in WP Rocket settings
- Investigating the Action Scheduler queue for stale or runaway jobs
- Replacing WP-Cron with a real server-side cron job for more reliable scheduling
3. Plugin Deactivation
Non-essential or conflicting plugins were deactivated to reduce background load:
- Imagify — redundant with Smush; deactivated
- WooCommerce HubSpot Sync — deactivated (HubSpot email sends don't require a live site connection)
- Additional low-priority plugins reviewed for deactivation
4. WP Engine Tracer
WP Engine was engaged and placed a performance tracer on the site to capture server-level diagnostics during error events.
Open Items (at time of meeting)
- [ ] Investigate database table sizes and autoloaded data via console — large autoloader data can cause timeouts
- [ ] Evaluate replacing WP-Cron with a real server cron job for more reliable scheduling
- [ ] Review Action Scheduler queue for stale jobs that can be cleared
- [ ] Follow up with WP Engine on tracer findings
- [ ] Confirm whether Imagify removal and HubSpot Sync deactivation resolved error frequency
Key Decisions
| Decision | Rationale |
|---|---|
| Replace Turnstile with WooCommerce V3 Captcha | Turnstile was blocking legitimate orders; V3 is invisible to real users |
| Deactivate Imagify | Redundant with Smush; two image optimizers conflict and add cron load |
| Deactivate WooCommerce HubSpot Sync | Polling every 5 minutes added unnecessary server load; HubSpot email sends don't require live site sync |
| Keep main HubSpot plugin active | Newsletter signup forms depend on it for subscriber capture |
| Keep Klaviyo active | Actively used for email marketing |
Generalizable Lessons
This case illustrates a common WordPress performance pattern:
Accumulated plugins each add background scheduled tasks. Under sufficient load, these cron jobs compete for server resources simultaneously, causing gateway timeouts — even when no single plugin appears problematic in isolation.
Diagnostic approach that worked well:
1. Export the WP cron job list (via a cron management plugin)
2. Use an LLM to analyze the job list and identify high-frequency or high-cost processes
3. Cross-reference with active plugins and disable redundant or non-essential ones
4. Engage hosting support (WP Engine) for server-level tracing in parallel
See also: [2] (if created)
Related
- [3]
- [4]