WooCommerce described a July 31 incident where an 800,000-recipient newsletter roughly doubled edge requests from about 500,000 to more than one million and caused a three to four minute partial outage. Email security scanners can open many links at machine speed, so a cohort plan based only on historical human click-through rate can materially underestimate the first-minute request wall.
Use this for WooCommerce marketers, infrastructure teams, agencies, and incident owners planning newsletters, product drops, flash sales, abandoned-cart sends, or any campaign that points a large audience at a shared page and checkout path.
Quick answer
Estimate the burst at the edge first, then translate cache misses into origin demand. Start with recipients per cohort multiplied by the measured scanner request factor plus expected human sessions, divide by the cohort release window, and apply cache-hit assumptions by asset class. Keep a tested reserve for checkout, APIs, background jobs, and ordinary traffic. The calculator should produce a starting cohort, not permission to send blindly. Real-time hold rules must stop the next cohort when 429, 5xx, latency, cache, or checkout guardrails fail.
What to check first
- Measure normal edge requests per second, origin requests per second, cache-hit ratio by path, origin latency, 429 and 5xx rates, PHP workers, database connections, and checkout success during a comparable quiet window.
- Send a small representative cohort and classify first-minute requests using request timing, link fan-out, cookie continuity, IP ownership, asset graph, user agent, conversion behavior, and repeated scanner signatures.
- Calculate scanner requests, human page and asset requests, expected cache misses, redirect requests, tracking requests, API calls, and safety reserve separately instead of using one blended multiplier.
- Define automatic hold thresholds for edge 429, origin 5xx, p95 HTML and Store API latency, cache-hit ratio, current JavaScript chunk availability, cart errors, and checkout completion.
- Increase the next cohort only after the prior cohort reaches a stable observation window and the named marketing plus infrastructure owners both approve the evidence.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Measure the quiet baseline | Measure normal edge requests per second, origin requests per second, cache-hit ratio by path, origin latency, 429 and 5xx rates, PHP workers, database connections, and checkout success during a comparable quiet window. | Predicted and observed edge requests, origin misses, scanner share, human sessions, and orders are recorded for every cohort. |
| Calibrate a small cohort | Send a small representative cohort and classify first-minute requests using request timing, link fan-out, cookie continuity, IP ownership, asset graph, user agent, conversion behavior, and repeated scanner signatures. | A scanner-shaped rehearsal stays within documented 429, 5xx, p95 latency, cache, Store API, cart, and checkout budgets. |
| Calculate edge and origin demand | Calculate scanner requests, human page and asset requests, expected cache misses, redirect requests, tracking requests, API calls, and safety reserve separately instead of using one blended multiplier. | The hold control stops a scheduled cohort and records who can resume it, which evidence is required, and how duplicate sends are prevented. |
| Set automatic hold guardrails | Define automatic hold thresholds for edge 429, origin 5xx, p95 HTML and Store API latency, cache-hit ratio, current JavaScript chunk availability, cart errors, and checkout completion. | A clean desktop and mobile buyer can load the campaign page, add to cart, pay, and receive confirmation throughout the monitored peak. |
Why this usually happens
- Security scanners may detonate each tracked URL immediately after delivery and request linked assets without human reading delays.
- A high global cache-hit ratio can hide expensive misses on the campaign landing page, redirects, Store API, or versioned JavaScript chunks.
- Autoscaling reacts after metrics cross thresholds, while the steepest part of the scanner burst can arrive within seconds.
- Marketing platforms may add redirect and query variants that fragment cache keys and multiply apparently unique requests.
Field notes
- Keep separate values for edge capacity and origin capacity. CloudFront can accept traffic that the application origin cannot process safely.
- Use the first cohort to improve the model. Store predicted versus observed scanner requests, cache misses, human sessions, orders, and errors.
- Recalculate after landing-page code, redirect rules, CDN configuration, email provider, security scanner mix, or checkout extensions change.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
recipients_per_cohort: 40000
scanner_requests_per_recipient_p90: 1.6
human_sessions_first_5m: 2400
edge_requests_estimate: 66400
cache_hit_ratio_floor: 0.94
origin_rps_budget: 120
hold_if_5xx_percent: 0.5
hold_if_checkout_success_below: 98.5
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Measure the quiet baseline
- Calibrate a small cohort
- Calculate edge and origin demand
- Set automatic hold guardrails
- Increase cohorts only from evidence
Decision rule
Release the next cohort only when observed edge and origin demand remain below tested capacity with reserve, current chunks load, cache hit ratio stays above its floor, error and latency budgets hold, and checkout success remains above the business threshold.
What to tell the client or owner
Give the owner the affected versions, exact workflow, observed result, business impact, evidence location, temporary control, named owner, and next review time. Remove credentials and personal data from shared screenshots and logs.
Production verification checklist
- Predicted and observed edge requests, origin misses, scanner share, human sessions, and orders are recorded for every cohort.
- A scanner-shaped rehearsal stays within documented 429, 5xx, p95 latency, cache, Store API, cart, and checkout budgets.
- The hold control stops a scheduled cohort and records who can resume it, which evidence is required, and how duplicate sends are prevented.
- A clean desktop and mobile buyer can load the campaign page, add to cart, pay, and receive confirmation throughout the monitored peak.
Mistakes to avoid
- Do not change several plugins, cache rules, firewall settings, or integrations before preserving a baseline.
- Do not treat one successful browser test as proof for APIs, background jobs, alternate roles, webhooks, or mixed-version fleets.
- Do not paste secrets, personal data, complete production payloads, or customer records into tickets, screenshots, or long-lived logs.
- Do not close the test until the user-visible result and server-side evidence agree.
Questions teams ask during testing
What scanner multiplier should every store use?
There is no universal number. Measure a representative cohort for your email provider, audience, links, CDN, and security scanner mix.
Can a high cache-hit ratio guarantee checkout safety?
No. Checkout and many Store API requests are dynamic, and a small percentage of misses can still exceed origin capacity.
Should cohorts grow by a fixed percentage?
Use observed headroom and stable guardrails. A fixed increase can be too aggressive when traffic shape changes between segments.
When HandL WP should help
Bring in HandL WP when a production checkout, form, editor, firewall, search visibility, or attribution workflow is at risk. We can preserve evidence, isolate the failing layer, make a narrow corrective change, and verify the result across WordPress, connected services, logs, and the user journey.
If this is active on a production site, plan a WooCommerce campaign capacity test.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references