> For the complete documentation index, see [llms.txt](https://docs.testvibe.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.testvibe.com/troubleshooting/run-failed.md).

# Run Failed

A failed run means at least one test did not complete successfully. It does not always mean the application is broken. The failure may come from the app, the test, the target data, or the environment the cloud test session ran against.

## First Review

1. Open the run detail page.
2. Filter to failed tests.
3. Open the failed row or scenario.
4. Read the error message.
5. View the screenshot or video near the failed step.
6. Open console, network, or trace evidence if the visual evidence is not enough.

## What Failed?

| Evidence                        | Possible meaning                                                                                |
| ------------------------------- | ----------------------------------------------------------------------------------------------- |
| Screenshot shows the wrong page | The test started at the wrong URL, login failed, or navigation changed.                         |
| Element not found               | The app UI changed, the selector is unstable, or the step ran too early.                        |
| Timeout                         | The app was slow, the session could not reach the site, or the test waited for the wrong thing. |
| Console error                   | The application may have thrown a browser-side error.                                           |
| Network error                   | An API call failed, was blocked, or returned unexpected data.                                   |
| No tests executed               | The selected test, dependency, or run setup may be wrong.                                       |

## Decide The Next Action

| If the evidence shows             | Do this                                                        |
| --------------------------------- | -------------------------------------------------------------- |
| The application behavior is wrong | Fix the app or test environment, then re-run.                  |
| The test expects old behavior     | Edit the feature or generated code.                            |
| The locator or timing is weak     | Regenerate or edit the Playwright test.                        |
| Test data is missing              | Add prerequisites, secrets, or setup data.                     |
| The session cannot reach the site | Check the site URL; for private apps, check the tunnel device. |

## Before Re-Running

Re-run after you make a meaningful change. Re-running without changing anything is useful only when the failure looks temporary, such as a network timeout or a staging outage.

Choosing **Re-run** on the run opens the run composer pre-filled with that run's tests and configurations, targeting the same site URL — nothing starts until you choose **Start Run**. Use the composer to narrow the retry to just the failed tests instead of repeating the whole run. See [Cancel or re-run tests](/run-tests/cancel-or-rerun-tests.md).

## Related Help

* [Inspect failed steps](/results/inspect-failed-steps.md)
* [Open traces](/results/open-traces.md)
* [Cancel or re-run tests](/run-tests/cancel-or-rerun-tests.md)
* [Tunnel devices](/account-settings/tunnel-devices.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.testvibe.com/troubleshooting/run-failed.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.