K6 load testing before a product launch: a practical test plan

Model the launch traffic

Use product forecasts, campaign mechanics and existing analytics to estimate arrival rate, session mix, geography and data variation. Separate read-heavy browsing from state-changing requests.

Document assumptions. A test that simulates more virtual users is not automatically more realistic.

Agree pass and stop criteria

Define latency and error thresholds for each important journey. Add infrastructure or cost constraints where they affect the launch decision. Stop the test if data integrity, downstream safety or system recovery is at risk.

• Target request or journey rate
• Latency percentile by operation
• Application and dependency error rate
• Queue depth or database saturation
• Autoscaling behaviour and warm-up time
• Recovery time after load drops

Run tests in a useful sequence

Start with a reproducible baseline. Add a steady-state test, then a ramp or spike that reflects the launch. Run a constrained failure or recovery scenario only when safeguards and rollback are ready.

Experience from a large campaign platform

Saikat designed K6 capacity and resilience tests for a campaign platform serving more than 22 partners. The supplied experience record describes scenarios at very large request scale, multi-node EC2 target groups and autoscaling decisions.

Those figures are evidence of individual experience, not a benchmark for another system. A new test plan should use the client's traffic model, architecture and risk limits.

Prepare test data and telemetry before generating load

Performance scripts need varied, valid data. Reusing one account, product or cache key can create contention or cache behaviour that real traffic will not produce. Decide how identities and records are created, refreshed and cleaned up, and protect any sensitive data. Make state-changing scenarios idempotent where possible or isolate their test data.

Synchronise the K6 run with application, infrastructure and dependency telemetry. Capture request rate, latency distribution and errors alongside database connections, slow queries, queue depth, cache behaviour, external-service limits, container or host resources and autoscaling events. Clock alignment and run identifiers make later correlation much easier.

Warm-up and background activity should be documented. A cold cache may be the correct launch risk, while a fully warmed environment may represent steady state. Existing batch jobs or shared test traffic can distort results, so record what else used the environment during each run.

• Representative accounts, records, request mix and data variation
• Safe creation, reuse and cleanup of state-changing test data
• Application, database, queue, cache and infrastructure telemetry
• Run identifier, clock alignment and configuration snapshot
• Known third-party limits and safeguards against unintended traffic

Turn load-test results into a launch decision

The report should begin with the traffic model, environment, version and pass criteria. Show latency distributions and error categories by journey rather than one global average. Relate changes in user-visible performance to dependency saturation, scaling behaviour or application limits, and distinguish observation from inference.

Repeat important tests after a change. A single successful run may be affected by cache state, noisy neighbours or transient dependency behaviour. Reproducibility is especially important when the result determines capacity purchase or a public launch.

End with a decision and conditions: ready for the target load, ready with a stated operational safeguard, or not ready until named work is complete. Record residual risks, owner and the monitoring thresholds that will be watched during the real event.

Frequently asked questions