Run status

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:

Every step that executed passed.
No coverage gap was left, so nothing you asked for went unchecked.
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.

Introduction

Getting started

Test creation

Test execution

Projects and configuration

Integrations

Troubleshooting

Resources

Run states

Step states

How the overall status is decided

Failure causes

Other run signals

​Run states

​Step states

​How the overall status is decided

​Failure causes

​Other run signals

Run states

Step states

How the overall status is decided

Failure causes

Other run signals