# Validate and fix a scenario

Validation runs one browser session through the saved actions to check whether the scenario can execute.

## Before validation {#prepare}

Validation requires a verified target. The saved action list shows what will run; [Playwright compatibility and conversion](https://userlimit.com/documentation/reference/playwright-compatibility.md) explains which source calls are changed or omitted. A scenario marked Successful cannot prove an assertion the importer ignored.

## Run the validation {#check}

After saving the scenario, select **Validate scenario** or **Validate again** to run one browser session. UserLimit displays **Validation in progress** until the check finishes. A **Successful** result means the saved actions ran without a reported error; a Failed result identifies the earliest reported failed step. The action and error message provide a starting point for correcting the scenario and validating it again.

Validation is free and may run from a different location than the load test. Cancelling it returns the scenario to **Not validated**, although the browser session may continue for a short time. The [usage and billing](https://userlimit.com/documentation/reference/usage-and-billing.md) reference explains how validation and load-test usage are accounted for.

## Fix a changed product selector {#example}

Suppose the Click step expects “Canvas backpack”, but the site now labels the link “Canvas daypack”. “Could not find element on page” is consistent with that mismatch. Inspect the page, update the saved role selector to the actual unique label and validate again. Increasing all timeouts would leave the wrong selector unchanged.

## Common validation problems {#diagnose}

| Problem | What to check | Possible resolution |
| --- | --- | --- |
| Conversion mismatch | Compare source with saved steps. | Use supported calls and explicit await; inspect the new list. |
| Missing or ambiguous element | Inspect the label, selector, visibility and first matching element. | Use a stable specific selector and the correct page state. |
| Blocked or redirected target | Look at the destination, access logs and verification scope. | Coordinate authorised access; do not broadly disable protection. |
| Unexpected page state | Check consent, catalogue data, locale and prior actions. | Use supported actions that account for the page’s expected state. |

Waiting for an element is a readiness check, not proof of a purchase or server-side change. Page-state waits written in source may be ignored; UserLimit waits for pages and elements as it runs each step.

## Duration and session time limit {#proceed}

A successful validation supplies a duration estimate and an automatic **Session time limit**. The scenario’s **Custom limit** field allows a different limit in seconds, saved with **Save limit**. Leaving it empty uses the automatic limit. A validation on an idle site does not establish load capacity. Changes to a scenario require validation again. For persistent failures, the [troubleshooting guide](https://userlimit.com/documentation/help/troubleshooting.md) explains the available checks and how to contact support.

## Related guide {#next-step}

[Configure traffic and test settings](https://userlimit.com/documentation/runs/configure-traffic.md)