# Start, stop and monitor a run

A run starts browser sessions and collects their results in a report. Sessions can continue after the configured arrival window ends.

## Review and start {#review}

**Run test** on a test’s page opens the run confirmation. The [configuration](https://userlimit.com/documentation/runs/configure-traffic.md), [usage and billing](https://userlimit.com/documentation/reference/usage-and-billing.md) and [production safety](https://userlimit.com/documentation/help/production-safety.md) guides cover preparation. UserLimit validates scenarios that need checking before starting the load test. Your account must have enough available capacity for the run to start.

## Run status {#states}

| Visible label | Meaning | What to know |
| --- | --- | --- |
| Waiting | The run has not begun execution. | Session results are not yet available. |
| Validating | Required scenarios are being checked before load sessions begin. | Inspect any validation failure; Stop test cancels the pending load run. |
| Running | Browsers are preparing, scheduled work is starting or sessions are still finishing. | Monitor Concurrent users, Completed sessions and target health. Use Stop test if needed. |
| Passed | The run ended with recorded outcomes, no validation failure and a recorded failed-session rate at or below the threshold. | A partial stopped run can still show Passed. Session counts and any stop reason help explain the result. |
| Failed | A scenario failed validation, or recorded failures exceed the threshold. | Inspect the failed scenario or grouped errors before rerunning. |
| Stopped | The run ended without recorded session outcomes and without a scenario validation failure. | The stop reason explains why the run ended without session outcomes. |

A run you stop can still show Passed or Failed based on the results collected so far. Passed does not mean the requested workload was fully achieved or that your timing and business criteria were met.

## Why a run outlasts its Arrival window {#duration}

The configured Arrival window determines when sessions are scheduled to start, so a session launched near its end may continue until it finishes or reaches its timeout. A run can also remain active while UserLimit waits for missing results. If those results do not arrive in time, the final report includes a message about incomplete sessions.

Live results change as sessions finish. The final report includes the collected results and any failed or incomplete sessions.

## Stopping and failure conditions {#stop}

**Stop test** requests an end to the run, but some sessions may still start or continue until they finish or reach their time limit. Site monitoring remains necessary until traffic subsides because the stopped report can close before those sessions finish and may not include their subsequent activity.

UserLimit also stops a run automatically when the failed-session percentage exceeds the configured error threshold, once at least 10 sessions have recorded outcomes. A run stops when UserLimit detects that your included and bought hours are used up, unless auto top-up has bought more. Because usage updates and stopping take time, this does not provide an exact spending cap.

Validation or capacity problems can prevent billed sessions from starting at all. During execution, failures may instead involve individual actions, session timeouts, sessions that could not run or sessions that stopped reporting. The stop reason and failure details help distinguish these cases; the [troubleshooting guide](https://userlimit.com/documentation/help/troubleshooting.md) provides further guidance.

A stopped report may contain only part of the run’s results. Usage is based on the session time included in that report, as described in [usage and billing](https://userlimit.com/documentation/reference/usage-and-billing.md).

## Recurring runs {#schedule}

Recurring runs are configured in the Test’s **Schedule** tab by enabling **Run this test on a schedule**, choosing the recurrence and time, and selecting **Save changes**. Times use the account owner’s timezone; the displayed timezone and next occurrence help confirm the timing after timezone or daylight-saving changes. Clearing the same checkbox and saving disables recurrence when the campaign or permission to test ends.

A scheduled occurrence may be skipped if another run is in progress, domains are unverified, your hours are used up or capacity is unavailable. The next recurrence is still scheduled, and the run history shows which occurrences actually ran.

## Result notifications and sharing {#notifications}

The **Notifications** tab offers **By e-mail** and **In Slack** under **Notify me**, along with a **Webhook** field. **Connect Slack** links a Slack channel, and **Save changes** saves the notification settings. A missing notification does not necessarily mean the run failed to execute. Its status is available in the Test’s run history.

A notification webhook is outbound result delivery, not a public test-control API. For a completed or stopped run, **Share** opens the report’s sharing dialog. Under **Public link**, **Create link** makes the report accessible through a shareable URL. Anyone with the link can read the report; links do not expire automatically. **Turn off link** revokes access. Selecting **Create link** again creates a new URL. Review sensitive information before sharing.

## Related guide {#next-step}

[Read the report](https://userlimit.com/documentation/results/read-a-report.md)