Run your first test

This guide takes you through one test, from defining it to reading 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. A performance test started without preparation can take a system offline.

Create and run your first load test.

Plan the test

Before clicking New test, decide:

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

Create the test

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

2. Name the test with something clear like checkout-staging-baseline, and add a short description.

3. Add the target. For a quick start, 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. Use a managed cloud region for public targets and a private location for internal targets.

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

   

   The New test form. Name, target, load profile and locations are all 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 update as the run progresses.

   

   Run detail Overview tab. Latency, throughput and virtual users update 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 the data to decide what to do next.

• Latency. Look at p95 and p99, not the average. See p95 and p99 latency.
• Errors. Open the Errors tab and check error counts by status code and by request label.
• Logs. The Logs tab has the runner logs.
• Runner health. Confirm the runners were not saturated. A saturated runner can produce misleading latency numbers.

Add notes and tags to the run. Then the next person, you included, knows whether it 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 the charts your team uses.
• Schedule recurring tests: turn this run into a recurring baseline.