Run your first test

This guide walks through one full test creation, from defining the test to interpreting the result. If you have not signed in yet, start with Getting started.

Use a safe target

Pick a target you own or have explicit permission to load. Performance tests can knock systems offline if started without preparation.

Plan the test

Before clicking New test, decide:

• What are you measuring? Pick one specific question — for example, “Does checkout still serve under 200 ms p95 with 500 concurrent users?”.
• Which target? A staging environment is safer than production for a first run.
• Which load profile? Start small: a short duration, a low virtual-user count, a single location.

Create the test

1. Open the project where the test should live and click New test.

2. Give the test a clear name like checkout-staging-baseline and a short description.

3. Add the target. For a quick URL handoff, paste the URL. For a real scenario, upload your test files (see Upload test files).

4. Set a conservative load profile. Most teams start with 50 virtual users for 2 minutes from one location.

5. Pick the location — managed cloud region for public targets, private location for internal targets.

6. Save the test. The test page now shows everything needed to start a run.

   

   The New test form — name, target, load profile, and locations all live on this one page.

Start the run

1. From the test page, click Run.

2. Confirm the load profile and locations on the run dialog.

3. Click Start. The run moves from queued to allocating to running within seconds.

4. Watch the live results page. Latency, throughput, and errors stream in as the run progresses.

   

   Run detail Overview tab — watch latency, throughput, and virtual users stream in while the run is active.

If the run stays in queued or allocating, see Runners not allocating.

Read the first result

When the run reaches finished, you have all the data you need to decide what to do next.

• Latency — focus on p95 and p99, not average. See p95 and p99 latency.
• Errors — open the Errors tab and look at error counts by status code and by request label.
• Logs — runner logs are available in the Logs tab.
• Runner health — confirm runners were not saturated; a saturated runner can produce misleading latency numbers.

Add notes and tags to the run so the next person — including future you — knows whether this run was a baseline, a regression, or an experiment.

Where to go next

• Read run results and logs — what to look at and in what order.
• Build reporting dashboards — pin charts that matter for your team.
• Schedule recurring tests — turn this run into a recurring baseline.