# Reading run results

The Runs page is where every execution lives, and where you diagnose what went wrong.

The Runs page in the sidebar lists every test execution across your account, newest first. You can filter by status to focus on failures, or by test if you are investigating a single journey. The list is paginated and lightweight enough to scroll through quickly. Click any row to open its detail view, which is where the actual diagnosis happens.

![A passing run detail page showing duration, step counts, pass rate, the expanded steps breakdown, and run details.](https://testsnag.com/images/docs/running-tests/reading-run-results-1-passed-run.r2.jpg)

Marked on the screenshot:
- The test name and overall outcome, with the reference, timestamp, and what triggered the run.
- Duration and step counts: total, passed, and failed at a glance.
- Pass rate for this run, so a partial failure is obvious without opening anything.
- Steps breakdown. Failed steps expand first; passed and skipped groups collapse.
- Run details: entry URL, runner, trigger, and timings.
- The three-dot menu: watch or share the recording, open the test, and file the failure as a ticket.

## The run header

The detail view header shows the overall status and the metrics that matter most: total duration, total step count, how many passed, how many failed, and the resulting pass rate as a percentage. A coloured bar visualises pass rate at a glance, with green for healthy, amber for partial, and red for severe. These numbers are useful even on passing runs because trends in duration are often the first signal that something is degrading before it actually breaks.

## Step by step

Below the header, every step is laid out in order with its status icon and type. Failed steps expand by default so the failure is the first thing you see, while passed steps stay collapsed so the page is not noisy. Each step carries the screenshot taken as it finished, not only the failing one, so you can walk forward through the run and see the exact point the screen stopped looking right. A failed step adds its error message and any extra context the runner captured, for example a network response body for an API step, or a DOM dump for a missing element. Most failures can be diagnosed without leaving this view.

[Video: Opening a failed run from the Runs list and expanding the failed step to reveal the error message.](https://testsnag.com/images/docs/running-tests/reading-run-results-2-triage.r1.gif)

## How the run was triggered

If the run was triggered by something other than a manual click, that context appears in the side panel. Scheduled runs show their schedule. Webhook runs show the JSON payload that was posted. GitHub deployment runs show the repository, the commit SHA, and the environment that was deployed. This metadata is the bridge between "this test failed" and "what was deployed when it failed", which is usually what you actually need to know to fix the problem.

## Screenshots on every step

Screenshots are captured per step on web and mobile runs alike, on passing steps as well as failing ones. That matters more often than it sounds: the step that throws is frequently not the step that broke, and being able to scroll back to the last screen that looked correct is usually what identifies the real culprit. A long run is capped so a very large suite cannot fill the page with images.

## The actions menu

The buttons at the top of a run are deliberately few: Stop Run while it is going, and Rerun once it has finished. Everything else sits behind the three-dot menu beside them, which holds Watch recording, Open Test, Share recording, Send to each connected issue tracker, and Resend webhooks. If you are looking for an action that used to be a button in the header, that is where it went.

## Watching the recording

When a recording is available, Watch recording in the three-dot menu replays what actually happened. This is invaluable when the screenshots and error message do not quite tell the whole story, for example when an animation, a transient toast, or a timing issue was the root cause. Tests still in progress poll live, so you can watch a long run progress without refreshing the page, and the page updates automatically the moment the run completes.