Tests and runs

In MaxoPerf the unit you create is a test, and the unit you execute is a run. The two ideas are intentionally separate so you can re-run the same test as many times as you need and compare results side by side.

Tests

A test is a reusable definition. It captures:

• The test files (Taurus YAML, JMeter JMX, k6 script, or supporting assets).
• The target — the system you are testing.
• The load profile — number of virtual users, duration, and request-rate intent.
• Where the load comes from — managed cloud locations or your own private locations.
• Data and secret bindings (see Data entities and Manage test secrets).
• An optional schedule for recurring execution.

A test lives in a project (see Accounts, workspaces, and projects). You can edit a test at any time without affecting the runs it has already produced.

The Tests list is where every reusable test definition in a project lives, ready to be re-run any time.

Runs

A run is one execution of a test. Every run carries:

• The test definition at the moment the run started.
• The result data — latency percentiles, throughput, errors, logs, and runner health.
• Notes, tags, and dashboards you attach for later comparison.

Runs are immutable. Once a run finishes, its data is preserved as the historical record of what happened. If you change the test and re-run, the new run captures the new definition; the previous run keeps its original definition.

Each run keeps its own immutable snapshot of results — latency, throughput, and virtual users — on its Overview tab.

Run lifecycle

Every run moves through a predictable lifecycle. The status appears in the console and is also available through the API.

Status	Meaning
queued	The run is accepted and waiting for capacity to be assigned.
allocating	MaxoPerf is reserving the runners needed to generate load.
starting	Runners are spinning up and preparing to execute.
running	The test is actively generating load and producing results.
stopping	A cancel or natural end has been requested; runners are draining.
finished	The run completed; results are final.
failed	The run could not complete successfully. The run page explains why.
cancelled	A user cancelled the run before it finished.

A run usually reaches running within seconds. If a run stays in queued or allocating for longer than expected, see Runners not allocating.

Status badges on the Runs list mirror the lifecycle table above, so you can spot a stuck or failed run at a glance.

Where to go next

• Run your first test — a guided path from a new project to a finished run.
• Read run results and logs — what to look at when a run finishes.
• Run stuck or failed — diagnose runs that do not behave as expected.