RESOURCES
Website capacity testing
Validate catalog, cart, and checkout paths before campaigns — separately from a pretty cached homepage.
Separate cache from conversion
A high cache-hit homepage can hide a fragile checkout API. Run distinct scenarios for browse traffic and conversion traffic, and watch origin metrics behind the CDN.
See Black Friday playbook, testing behind Cloudflare, and the use-case sibling CDN / WAF testing.
Campaign checklist
- Agree the test window with NOC and providers.
- Instrument edge and origin together.
- Document WAF/rate-limit rollback if legitimate users get challenged.
- Abort when error rate or origin latency exceeds the pre-written budget.
Compare plans on pricing. Broader framing: authorized load testing · all use cases · start free.
Common pitfalls on public sites
Website capacity runs fail when teams treat “homepage survived” as proof the storefront is ready. Cached HTML and edge assets absorb browse traffic while cart, login, search, and payment callbacks still hit a thin origin. Another frequent miss is mixing marketing bots, synthetic monitors, and real campaign traffic into one chart — you cannot tell which cliff belonged to which path.
Also avoid ramping every region and every URL at once. Pick one conversion journey, one region set, and one abort rule. If WAF challenges spike on legitimate checkout cookies, pause and adjust rules before you keep spending Hub capacity. For vocabulary, see the glossary; for legal framing, start at authorized load testing.
Recommended run sequence
- Verify the hostname and confirm the change window with on-call and CDN admins.
- Smoke the Hub method for 30–60 seconds at Concurrent 1; confirm charts and origin logs move.
- Run a browse-only Layer 7 scenario (catalog or landing) and record cache-hit and origin CPU separately.
- Run a conversion scenario (cart → checkout APIs) with the same abort budget; do not reuse the browse plateau as a pass.
- Cool down for several minutes and check sticky queues, connection reuse, and error tails before the next step.
Size concurrents on pricing and the concurrent vs RPS calculator. Start a limited rehearsal with a free trial.
Metrics to watch on edge and origin
- Edge: cache hit ratio, WAF challenge rate, origin request rate, and anycast health across regions.
- Origin: p95/p99 latency on cart and checkout APIs, 5xx rate, DB pool wait, and NIC saturation.
- Hub: achieved RPS vs open concurrents — rising workers with flat RPS usually means wait, not throughput.
- Business: payment provider timeouts and inventory lock latency if those paths are in scope.
Pair this use case with CDN / WAF testing when the edge is part of the risk. Deeper campaign notes live on the blog Black Friday and Cloudflare guides.
When not to use a website stress run
Skip a full website capacity window if you only need a protocol regression on a single API contract — use scripts in CI or a narrow API load testing scenario instead. Do not schedule production peaks during unrelated incidents, unfinished deploys, or when authorization covers only staging. Hub tests are for infrastructure you own or may exercise in writing; third-party storefronts and “competitor sites” are out of scope under Acceptable Use.
Hub tip: keep one verified target per campaign property, name scenarios by journey (browse vs checkout), and stop from the panel the moment abort criteria fire. Developer automation paths are documented in docs.
Related
Resources hub · Glossary · Tools matrix · RPS calculator · Useful network tools · Blog · Pricing · Start free