# Test campaign and launch readiness

A sequence of comparable runs can help assess whether a scenario meets the performance targets for a launch.

## Choosing a launch workload {#objective}

A useful launch test represents the traffic expected during a busy period, such as a previous campaign’s busiest ten minutes. Monthly visitor totals alone do not describe a launch peak. When the forecast is uncertain, a range of workloads can show how the scenario behaves under different levels of traffic.

## Example test plan {#plan}

| Field | Fictional example |
| --- | --- |
| Environment / release | Authorised staging, release B, warmed catalogue cache. |
| Scenario / exclusions | Campaign landing page to product detail. No login, cart, orders or payments. |
| Requested workload | 600 sessions over 600 seconds, Constant load, one location. |
| Estimated session time and usage | 20–45 seconds per session; approximately 3.33–7.5 VUh. |
| Criteria | 600 completed sessions, no early stop, at most 1% failed sessions and average page-load time no greater than two seconds. Completed sessions includes failed outcomes and does not confirm exact start times. |
| Stop responsibility | The site operator monitors site health and can stop the run if it affects visitors. |
| Evidence | The run report and site monitoring from the same period. Site monitoring helps confirm whether the intended traffic reached the website. |

These criteria and counts illustrate a plan, not recommended thresholds for every website. The automatic error threshold can stop a run with too many failures, but does not assess all of these performance targets. Review [usage and billing](https://userlimit.com/documentation/reference/usage-and-billing.md) and [production safety](https://userlimit.com/documentation/help/production-safety.md) before committing to the workload.

## A typical testing sequence {#sequence}

After permission to test has been established, [scenario validation](https://userlimit.com/documentation/journeys/validate.md) checks whether the scenario can execute. A small baseline run then provides an initial comparison before the intended launch workload is tested with [monitoring and someone available to stop the run](https://userlimit.com/documentation/runs/lifecycle.md).

The resulting session outcomes, timings and any stop reason can be compared with the agreed performance targets. When a failure needs investigation, a repeat under similar conditions after a specific fix helps establish whether the change improved the result. The release decision can then be updated to reflect the new findings and any remaining limitations.

## Interpreting launch readiness {#decision}

The results may meet the test’s performance targets, fall short of them or leave readiness uncertain. These conclusions depend on the test’s scope as well as its results. For example, if blocked sessions prevented the intended workload, fast timings alone cannot establish readiness.

Example: “Release B exceeds our limits for the browsing scenario: 40 of 600 completed sessions failed (6.67%) and average page-load time was 3.1 seconds. We will inspect the failed product step and retest after the fix. This decision concerns the tested staging path and workload; production traffic, payment and checkout were excluded.”

A later run can change this conclusion, although environment differences and missing samples may still limit the comparison. [Run this workflow in UserLimit](https://userlimit.com/tests/new).

## Related guide {#next-step}

[Explain the result to a client](https://userlimit.com/documentation/recipes/client-summary.md)

[Ecommerce load testing before peak season](https://userlimit.com/ecommerce-load-testing)