Skip to content
Pricing Open UserLimit
Help and account

Test production safely

Production tests can affect visitors and connected services. Permission, site monitoring and a way to stop the run help manage that impact.

Authority and scope

Permission to test needs to cover the hostname, environment, time window and workload. Domain verification is a product eligibility check, not blanket authorisation. A small load can still affect a fragile production site.

A scenario may call hosting, CDN, identity, analytics, payment, email and other third-party services. Permission to test the page does not automatically cover these dependencies. A staging environment may be more suitable when the impact on production or connected services is uncertain.

Safe scenario and data

Read-only browsing is a useful starting point. Scenarios that place orders, send messages, change stock or create accounts can have lasting effects. These tests need suitable test accounts and data, arrangements with affected providers and a cleanup plan.

Do not paste production credentials into scripts, external assistant prompts, report examples or support requests. Each session starts in a fresh browser context without your existing login. Review Playwright compatibility and conversion so a skipped assertion does not create false confidence about the outcome.

Workload and stop responsibility

A small initial workload helps reveal unexpected effects before more traffic is introduced. Someone needs to be available to monitor site health and stop the run when agreed conditions are reached. The automatic error threshold provides one control, but it does not replace observation of the site and its connected services.

The response plan should account for the fact that stopping a run does not end all traffic immediately and that usage can exceed an estimate. Temporary access rules should remain limited to the test’s scope and duration, with a rollback or other operational response available if the test affects normal service.

Testing in stages

Validation checks whether the saved scenario can execute, after which a small baseline run provides an initial view of session outcomes and site health. A larger workload becomes useful once the baseline results are understood and the next stage is within the permitted test scope.

If a run has an unexpected impact, it should be stopped while site monitoring continues. Some sessions may remain active after the stop request, so the absence of an active run in UserLimit does not by itself confirm that traffic has ended.

Cleanup and follow-up

Even an intended read-only scenario can affect analytics or connected services, while stateful scenarios may leave carts, queued messages, test records or inventory changes. Follow-up work should account for these effects and remove temporary access rules or report links that are no longer needed.

A summary can capture the result and any follow-up work. The troubleshooting guide covers unexpected results.

Related guide

Complete the pre-run review

Esc

Documentation

What UserLimit tests Run your first load test Verify a domain Sessions, arrivals and concurrency Create and import a scenario Validate and fix a scenario Configure traffic and test settings Start, stop and monitor a run Read a load-test report Test a storefront browsing scenario Test campaign and launch readiness Write a client-facing test summary Playwright compatibility and conversion Metrics and measurement Usage and billing Troubleshoot a failed or misleading test Test production safely Contact support
↑↓ to move to open