> ## Documentation Index
> Fetch the complete documentation index at: https://docs.testorim.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Run status

> Run states, step states, and how the overall verdict is decided.

## Run states

| State       | Meaning                                                        |
| ----------- | -------------------------------------------------------------- |
| `pending`   | The record exists; execution has not started.                  |
| `running`   | Steps are executing.                                           |
| `completed` | The run finished. Whether it **passed** is a separate field.   |
| `failed`    | The run could not complete: a setup error, a crash, a refusal. |
| `cancelled` | Stopped by you, or reclaimed by the sweeper.                   |

A completed run also carries an **overall status** of `passed` or `failed`.
`completed` means "it ran to the end"; `passed` means "and everything was
fine". The CLI and API report the overall status.

## Step states

| State     | Meaning                                                                                         |
| --------- | ----------------------------------------------------------------------------------------------- |
| `passed`  | The action succeeded, or the assertion held.                                                    |
| `failed`  | It did not. Carries a cause and usually a screenshot.                                           |
| `skipped` | Never executed: the run was cancelled, or an earlier step failed and made this one meaningless. |

A step can also pass **with a warning**: the action worked, but something is
worth knowing. The app moved the page mid-step. An Enter key was ignored and a
click stood in for it. A typed value was no longer in any visible field by the
end of the run. A resolution had to guess and is telling you what it picked.

Warnings do not fail a run. They are the difference between a green test you
trust and one you should look at.

## How the overall status is decided

A run passes when **all** of these hold:

1. Every step that executed passed.
2. No coverage gap was left, so nothing you asked for went unchecked.
3. The report's own verdict agrees.

If the report disagrees with the steps, a synthetic failed step is appended and
the run fails. Prose never overrides observation, and prose never *creates* a
failure either: only an executed, failed step can say the app misbehaved.

## Failure causes

| Cause         | Whose problem                                                                                                                              |
| ------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| `app`         | The site under test. A real defect.                                                                                                        |
| `test`        | The step does not match the page: target not found, ambiguous, the typed value did not stick, the condition is not valid for that element. |
| `unsupported` | Outside what a browser step can observe at all.                                                                                            |
| `capacity`    | The plan hit its 40-step ceiling before covering a requirement.                                                                            |
| `omission`    | The plan had room and simply never covered it.                                                                                             |
| `internal`    | Testorim's own runner broke.                                                                                                               |

An internal failure is deliberately excluded from three things: the silent
retry budget, another lap of a long-polling assertion, and a "rejected as
expected" pass on a negative test. Only the application refusing an action can
satisfy a negative test.

## Other run signals

| Signal                 | Meaning                                                                                                                          |
| ---------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| **Passed after retry** | The step failed once and passed on a second attempt. Mild flake signal.                                                          |
| **Performance status** | `degraded` when a page breached the procedure's LCP/FCP/TTFB budget. Alerts like a failure.                                      |
| **Visual result**      | A pixel diff against the saved baseline for that step and viewport.                                                              |
| **Coverage check**     | `unavailable` when the coverage judge could not run. The run's status is unchanged, but the plan was not independently verified. |


## Related topics

- [Get one run with all artifacts](/api-reference/runs/get-one-run-with-all-artifacts.md)
- [API reference](/api-reference/introduction.md)
- [Browser failures](/troubleshooting/browser-failures.md)
- [Slack](/integrations/slack.md)
- [Platform overview](/developers/platform-overview.md)