Skip to content
MaxoPerf MaxoPerf docs

Run stuck or failed

A run that misbehaves usually fits one of a few categories. Work through the list from the top. The first three checks catch most issues.

1. Check the run status

Section titled “1. Check the run status”

Open the run page and read the status field. The lifecycle is queued → allocating → starting → running → stopping → finished, with failed or cancelled as terminal states. If the run is stuck before running, see Runners not allocating.

2. Confirm the test files are valid

Section titled “2. Confirm the test files are valid”

When a run starts and then fails instantly, a test file is often the cause:

  • The entrypoint file is wrong or missing.
  • A referenced data file wasn’t uploaded.
  • A k6 script imports a module that isn’t in the bundle.

Open the Files tab on the test and check that every file is there. The console shows a validation error next to each unresolved reference.

3. Read the failure cause

Section titled “3. Read the failure cause”

A failed run names a cause, such as Playwright found no tests, Page navigation timed out or Runner overloaded. For browser tests, the engine’s own error text appears under the cause. See When a run fails for what each browser-test cause means and what to change.

4. Check the target

Section titled “4. Check the target”

If the runners started but most requests failed:

  • Can the location you picked reach the target? Public targets need a managed location. Internal targets need a private location.
  • Did the target return errors? Open the Errors tab and read the response bodies. See Inspect error response bodies.
  • Is the target rate-limiting you? A burst of 429s usually means it is.

5. Check runner health

Section titled “5. Check runner health”

A saturated runner reports misleading latency. Open the Overview tab and look at runner CPU and memory.

  • If CPU or memory sits at 100%, the runner couldn’t generate the load you asked for. Lower the virtual users per runner or add runners.
  • If runner health is fine, the latency is real and the target is slow.

6. Check secrets and data

Section titled “6. Check secrets and data”

If the run completed but every response was an auth failure:

  • Check that the test’s secret bindings point to the right project secrets.
  • Check that the project secret values are still valid.
  • Check that the data variant the run used has the credentials you expect.

See Manage test secrets and Data entities, parameters, and variants.

7. Check capacity limits

Section titled “7. Check capacity limits”

If a run fails with a quota or limit message, your plan is the cause:

  • The concurrent run limit is reached.
  • The run exceeds the virtual-user limit per run.
  • A required capability (for example, private locations) isn’t on the current plan.

When this happens, the run page links to the plan-switch flow. See Upgrade or cancel your plan.

When you have hit the end of the list

Section titled “When you have hit the end of the list”

If nothing above explains the problem, send the run ID to support through the Support page. The run ID is in the URL of the run detail page.

Where to go next

Section titled “Where to go next”