# 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 {#authority}

Permission to test needs to cover the hostname, environment, time window and workload. [Domain verification](https://userlimit.com/documentation/get-started/verify-domain.md) 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 {#journey}

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](https://userlimit.com/documentation/reference/playwright-compatibility.md) so a skipped assertion does not create false confidence about the outcome.

## Workload and stop responsibility {#workload}

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](https://userlimit.com/documentation/runs/lifecycle.md) does not end all traffic immediately and that [usage can exceed an estimate](https://userlimit.com/documentation/reference/usage-and-billing.md). 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 {#execute}

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 {#cleanup}

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](https://userlimit.com/documentation/recipes/client-summary.md) can capture the result and any follow-up work. The [troubleshooting guide](https://userlimit.com/documentation/help/troubleshooting.md) covers unexpected results.

## Related guide {#next-step}

[Complete the pre-run review](https://userlimit.com/documentation/runs/configure-traffic.md)