# Run your first load test

This guide covers a first load test: a verified domain, a read-only scenario, a small workload and the resulting report.

## 1. Before you begin {#prepare}

This example uses a read-only page on a public site that you control and have permission to test. The page should not place orders, send messages or change data, and someone should be available to monitor the site during the run. The [production safety guide](https://userlimit.com/documentation/help/production-safety.md) explains the considerations for a live environment.

[Domain verification](https://userlimit.com/documentation/get-started/verify-domain.md) requires access to the site’s DNS records or homepage HTML. You will also need available Virtual-User hours (VUh) or a subscription for the load test. Validation itself is free; the [usage and billing guide](https://userlimit.com/documentation/reference/usage-and-billing.md) explains how usage is calculated.

## 2. Verify the target {#verify}

Open **Domains → Add domain**. Enter the hostname, publish the issued DNS TXT record or meta tag, then select **Verify now**. Continue once the domain is verified.

## 3. Create one scenario {#build}

In **Scenarios**, a script can be pasted to create a scenario. This example opens one page. Replace the placeholder URL with your own verified URL; [Playwright compatibility](https://userlimit.com/documentation/reference/playwright-compatibility.md) explains the supported calls.

~~~javascript
await page.goto('https://your-verified-domain.invalid/catalogue');
~~~

Select **Create scenario**.

## 4. Inspect the converted actions {#inspect}

The saved scenario should contain one Open step with your URL. A descriptive name makes it easier to identify in reports. Once this page loads successfully, the scenario can be extended with more actions; see [scenario creation](https://userlimit.com/documentation/journeys/create-and-import.md).

## 5. Validate the intended action {#validate}

Select **Validate scenario**. **Successful** means the saved action ran without a reported error. A failure identifies a problem to resolve using [Validate and fix a scenario](https://userlimit.com/documentation/journeys/validate.md). This single session checks execution, not website capacity.

## 6. Review and run a small workload {#configure}

Create a Test, select this scenario at 100% traffic, set **10 sessions over two minutes**, choose **Constant load** and select just one available location. These example settings may need to be reduced to fit your site and the workload you have permission to run. Review Schedule and disable recurring execution for this first test.

If validation took twenty seconds, ten similar sessions would use approximately 200 Virtual-User seconds, or 0.056 VUh. Slower sessions use more. The test settings show a capacity check, usage estimate and error threshold; the [configuration guide](https://userlimit.com/documentation/runs/configure-traffic.md) explains each control. **Stop test** is available on the run view. Some sessions may continue after it is selected, so site monitoring remains useful until traffic subsides. See [stopping behavior](https://userlimit.com/documentation/runs/lifecycle.md#stop).

## 7. Open and inspect the report {#run}

Monitor the run from the Test page. Stop if it creates unexpected impact. The two minutes describe arrivals; the last session can finish later. Follow [the run lifecycle](https://userlimit.com/documentation/runs/lifecycle.md) if it stops early or stays active.

The finished report shows **Completed sessions**, a Passed/Failed/Stopped outcome, **Errors** or **Failed requests**, **Response times** and, in the owner’s report, **VUh billed**. Completed sessions counts reported outcomes, including failures; it is not a count of successful visits or exact browser starts. The report does not show exact session start times; see [session outcomes](https://userlimit.com/documentation/results/read-a-report.md#validity). A Passed label reflects the configured error threshold. It does not guarantee that the full workload ran or that your performance targets were met. A blocked or incorrect scenario needs to be resolved before a larger run can provide useful results.

## What the first test tells you {#done}

The saved scenario identifies the visit that was tested, while the report describes its recorded outcomes, failures and timings. The **VUh billed** value shows the recorded usage for the run. Together, these provide a baseline for comparing how the same scenario behaves as traffic increases.

[Start your first test](https://userlimit.com/tests/new)

## Related guide {#next-step}

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