Skip to content
MaxoPerf MaxoPerf docs

Run stuck or failed

A run that does not behave as expected usually falls into one of a few categories. Work the list top to bottom — most issues are caught in the first three checks.

1. Check the run status

Section titled “1. Check the run status”

Open the run page and look at 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”

A common cause of “started and then failed instantly” is a test file issue:

  • The entrypoint file is wrong or missing.
  • A referenced data file did not get uploaded.
  • A k6 script imports a module that is not in the bundle.

Open the Files tab on the test and confirm everything is present. The console shows validation errors next to each unresolved reference.

3. Check the target

Section titled “3. Check the target”

If the runners started but most requests failed:

  • Is the target reachable from the location you picked? Public targets need a managed location; internal targets need a private location.
  • Did the target return errors? Open the Errors tab and inspect the response bodies — see Inspect error response bodies.
  • Is the target rate-limiting? A burst of 429s usually points there.

4. Check runner health

Section titled “4. Check runner health”

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

  • If CPU or memory is pegged at 100%, the runner could not generate the load you asked for. Reduce virtual users per runner or add more runners.
  • If runner health is fine, the slow latency is real and points at the target.

5. Check secrets and data

Section titled “5. Check secrets and data”

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

  • Confirm the secret bindings on the test point to the right project secrets.
  • Confirm the project secret values are still valid.
  • Confirm the data variant the run used contains the credentials you expect.

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

6. Check capacity limits

Section titled “6. Check capacity limits”

A run that fails with a quota or limit message points at your plan:

  • Concurrent run limit reached.
  • Virtual-user limit per run exceeded.
  • A required capability (for example, private locations) is not on the current plan.

The run page links to the plan-switch flow when this happens — 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 none of the above explains it, send the run ID to support — see 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”