How much traffic does a young shop take before checkout slows down?
Online shop with a small catalog
Holds ~17 req/s on short steps (2.7 min), fails at ~29 req/s
First to slow down: Add to cart, p95 2–3 s against 1.5 s.
- Holds
- ~17req/s
- measured over 2.7 min
- Fails at
- ~29req/s
- judged by the SLO
Checked 6 of 12 steps at this rate; 6 not checked — too few samples (< 100 in the window)
- Choose shipping
- Place the order
- Start payment
- Open the payment session
- See shipping options
- Enter the address
rate steps of 1.6–3.9 min · checks: 79 passed, 7 failed, 34 too little data, 40 not run · sent 100 % of the plan · generator health not verified
Synthetic load sent from outside; your real traffic and server metrics are not part of it.
What to do next
- Confirm it with a load test at ~14 req/s.
- To check Choose shipping, Place the order, Start payment and 3 more, run at least 14 min at this rate: they had fewer than 100 samples.
300 products and a few hundred orders: a shop in its first months.
Example: a real CapacityLab Load Run against a shop we host
Test setup
Where the limit lies
Each dot is a rate the shop was held at for at least a minute and a half. It passes when every step of the visit with enough samples keeps its p95 latency inside the bound and errors under 1%; a rare checkout step with too few samples at that rate is shown as missing, not as passed.
- Did not hold 30 min13.5 req/s
- Held for 60 min13.5 req/s
- Did not hold 180 min13.5 req/s
- Held for 720 min13.5 req/s
- Slowed first
- Add to cart
- Latency bound
- p95 ≤ 1.5 s
Planned against delivered
The search climbs a staircase of rates. At each step our generators sent the planned rate; the bars show what the shop actually answered, and its p95 latency at that step.
| Planned | Delivered | p95 | Errors | Result |
|---|---|---|---|---|
| 10.1 | 10.3 | 400 ms | 0% | Held |
| 17 | 17.8 | 500 ms | 0% | Held |
| 28.5 | 28.4 | 1 s | 0% | Broke |
| 48 | — | — | — | Stopped |
- Add to cart: p95 3 s against the 1.5 s bound.
- 6 steps of the visit got less traffic than planned: visits slowed down and fell behind the schedule (lowest 82.4% of plan).
Which step slowed down first
p95 latency of each step of the visit at each rate, against the bound. The step the Result names as limiting is marked.
| Step of the visit | Share | 10.1 req/s | 17 req/s | 28.5 req/s |
|---|---|---|---|---|
Load the regionGET /store/regions | 2.9% | — | 75 ms | 200 ms |
Open categoriesGET /store/product-categories | 8.6% | — | 75 ms | 200 ms |
Browse the catalogGET /store/products | 29% | 75 ms | 100 ms | 300 ms |
SearchGET /store/products | 12% | 75 ms | 100 ms | 300 ms |
Open a productGET /store/products/{product_id} | 39% | 75 ms | 100 ms | 400 ms |
Add to cartLimitingPOST /store/carts | 2.9% | — | 1,000 ms | 3,000 ms |
Enter the addressPOST /store/carts/{cart_id} | 1.4% | — | — | — |
See shipping optionsGET /store/shipping-options | 1.4% | — | — | — |
Choose shippingPOST /store/carts/{cart_id}/shipping-methods | 1.4% | — | — | — |
Start paymentPOST /store/payment-collections | 0.7% | — | — | — |
Open the payment sessionPOST /store/payment-collections/{payment_collection_id}/payment-sessions | 0.7% | — | — | — |
Place the orderPOST /store/carts/{cart_id}/complete | 0.7% | — | — | — |
p95, SLO ≤ 1,500 ms
Holding it for longer
A capacity search finds the limit in minutes. Longer runs at a rate below it show whether the shop keeps holding: slow leaks, full queues and cold caches take time to show.
- Find the limitLimit found — provisionalHolds ~17 req/s on short steps (2.7 min), fails at ~29 req/sSep 30, 2026, 17:39 UTC
- Hold 30 minDid not hold13.4 req/s delivered, p95 400 ms, errors 0%Sep 30, 2026, 18:10 UTC
- Hold 1 hHeld13.6 req/s delivered, p95 400 ms, errors 0%Sep 30, 2026, 18:42 UTC
- Hold 3 hDid not hold13.5 req/s delivered, p95 400 ms, errors 0%Sep 30, 2026, 19:44 UTC
- Hold 12 hHeld13.5 req/s delivered, p95 400 ms, errors 0.03%Sep 30, 2026, 23:34 UTC
At 13.4 req/s for 30 minutes the shop kept a stable throughput and answered everything, but Choose shipping, Place the order reached a p95 of 2 s against the 1.5 s bound: the run did not attain its SLO. 2 of 4 longer runs at this rate missed the bound, so keeping the SLO at this rate is not confirmed.
What we saw on our own servers
This is the one part a Report does not contain: we host this shop, so we can read its hosting metrics. On your application you read your own dashboards; CapacityLab measures from the outside.
- Application (Node.js)1.71 vCPUMemory peak 568 MB
- Database (PostgreSQL)0.17 vCPUMemory peak 371 MB
- Cache (Redis)0.01 vCPUMemory peak 24 MB
The application was the busier side: its CPU peaked at 1.71 vCPU while the database stayed at 0.17. A Node.js process runs its JavaScript on one thread, so checkout work queueing for that thread is a likely cause of the slowdown; we did not test it directly.
None of 14,935 requests ended with a server error.
What you would do next
- Confirm before you plan
Run a load test at 13.6 req/s for 30 minutes: the search advises it as the rate to confirm next, and only the confirmation shows whether every step keeps its bound.
- Watch your side while it runs
Keep your own dashboards open during the run. The report says which step slowed; your metrics say why.
- Change one thing, then compare
After a change, run the same test again and put the two reports side by side.
Your own copy of this report is one sign-up away
Sign up with your email. Your new account opens with this report and every other demo report inside, ready to compare with your own first run.
Where these numbers come from
Exported from the published Reports of these Load Runs. The shop's CPU and memory come from its Railway metrics; its error count from its own access log.
Identifiers and checksums
| Load Run | Result digest | Computed |
|---|---|---|
cb2d4ac6-406a-49b3-8f17-e5e8d60906e7 | sha256:c23a8169490b2bbf0f1e209f3a1cec23277a487c410d0540e8396f75cdc3e072 | Sep 30, 2026, 17:50 UTC |
79157cd2-9038-4fe2-a4b8-babcd3c8f724 | sha256:dbd4acf035860c28a13410334f2022231904059433aae66eede26e800dda5b7c | Sep 30, 2026, 18:40 UTC |
950d737d-69cb-444d-aa0d-c98f69ca88c7 | sha256:4e3ae46977a2c2f84492d30b2491a277f2327cfa5e26f09d4238523ab8b5c824 | Sep 30, 2026, 19:42 UTC |
3c84f878-b51e-4691-861c-6bbe489777bd | sha256:4fc3848d76d69f6167ff40ef2785e3a296997bc17a0b2ca55ca9975641260416 | Sep 30, 2026, 22:44 UTC |
94412fc5-9c3d-4154-8b93-6be8313ee108 | sha256:b9b8ee159f287284e651b3cbe3619b18fb93414a4320ec3143ea86cd8a7591d7 | Oct 1, 2026, 11:36 UTC |