Inspect Failed Steps
The same failure read from a terminal: find the failed run, then print its whole context — the failing scenario, the assertion, the stack and the log tail — without opening a browser.
Failed rows are the starting point for triage. A failure may mean the application has a bug, the test needs an update, the target environment is not ready, or a shared dependency such as login or test data failed.
Open failure details
- Open Runs.
- Select the failed run.
- Open the Features tab.
- Find the failed scenario rows when the run has many.
- Open the failed row to expand its details.
The details view can show the scenario location, the error, the final screenshot, the video, and a Debug with AI button that opens the Playwright trace with an AI assistant.
Read the failure panel
Use the panel from top to bottom:
| Area | What to look for |
|---|---|
| Error | The Playwright error text, assertion output, and the failure source. |
| Location | The spec file and configuration that identify where the failure occurred. |
| Final screenshot | The browser state at the end of the failed scenario. |
| Video | The browser session leading up to the failure. |
| Debug with AI | Opens the full action-by-action Playwright trace with an AI assistant docked beside it that diagnoses the failure automatically. |
Decide what kind of failure it is
| Signal | Likely cause |
|---|---|
| Screenshot shows the wrong page | Navigation, login, or environment setup may be wrong. |
| Screenshot shows the expected page but the assertion failed | The test expectation may be too strict or out of date. |
| Error mentions missing selector or timeout | The UI changed, the app was slow, or the selector needs an update. |
| Error appears before the test reaches the app | Check session setup, dependencies, and secrets. |
| Many rows fail at the same prerequisite | Fix the prerequisite before editing individual tests. |
Use the next evidence layer
If the failure panel does not explain the problem:
| Need | Open |
|---|---|
| See the exact browser sequence | Watch videos |
| Inspect page actions, DOM snapshots, and request timing | Open traces |
| Check browser console errors or network requests | Open traces |
From the command line
The same failure context is available from a terminal, which is usually where you are when CI tells you something went red:
testvibe runs list --status failed
testvibe runs diagnose <runId>
diagnose prints the failing scenario, the assertion that failed, the stack, the
tail of the run log and links to the run's artifacts. Add --json to get the
Gherkin and the executed spec source alongside it.
The artifact links it prints are short-lived signed URLs. Treat them as
credentials — they grant read access until they expire, so avoid pasting
diagnose output straight into a public ticket or chat.
Setting up the CLI and its API key is covered in CLI & API keys.
After you make a change, re-run the smallest useful scope first. For re-runs, see Cancel or re-run tests.