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
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 explains the considerations for a live environment.
Domain verification 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 explains how usage is calculated.
2. Verify the target
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
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 explains the supported calls.
await page.goto('https://your-verified-domain.invalid/catalogue');
Select Create scenario.
4. Inspect the converted actions
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.
5. Validate the intended action
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. This single session checks execution, not website capacity.
6. Review and run a small workload
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 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.
7. Open and inspect the report
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 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. 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
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.