> ## 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.

# Screenshots, logs and evidence

> Everything a run captures, and where to find it.

Every claim in a Testorim report is backed by something that was recorded. This
is the full list.

## Screenshots and video

| Artifact               | When                                                                      |
| ---------------------- | ------------------------------------------------------------------------- |
| **Live stream**        | Frames roughly twice a second while the run is in progress. Not retained. |
| **Final screenshot**   | Once, after the page settles at the end of the run.                       |
| **Failure screenshot** | At the exact moment each failed step failed.                              |
| **Step screenshot**    | After a successful step, when that step has a visual baseline.            |
| **Video**              | The whole run.                                                            |
| **Trace**              | A Playwright trace for the run.                                           |

## Per-step snapshots

Each step records the page **before** and **after** it acted: the URL, the page
title, and the visible text. These are what let the report say that the address
moved between resolving a target and acting on it, and what the silent-failure
check compares: a submit-like click that changes neither the URL nor the
visible text is reported as a warning and fails the run.

## Assertion evidence

Every assertion stores three things: the matcher that decided it, the condition
that was expected, and the **actual state read back off the element**:
`enabled`, the text it held, the value in the input, or `not present`.

The report is required to quote the actual value and forbidden from inferring
an attribute nobody observed. A run that checked visibility cannot report that
something was disabled.

## Console and network

Console messages and network requests are captured per step, in the window
around the action. They appear on the run page and feed API assertions.

A step with an API assertion also stores the matched request: its URL, method
and status, or the reason nothing matched.

## Accessibility

The finished page is scanned and its violations stored with the run.

## Performance

Metrics are collected per page that loads: LCP, FCP, TTFB. If the procedure
has a [performance budget](/troubleshooting/reliability#performance-budgets),
a breach marks the run's performance status `degraded` and alerts like a
failure.

## Visual diffs

For a step with a saved baseline for that `(test, step, viewport)` combination,
a pixel comparison runs and the run page shows baseline, actual and difference
side by side.

## Downloads

A file a step downloads is captured and retained whether or not the step
asserted anything about it.

## Where to find it all

* **The run page** at `/runs/<run-id>`, holding everything above.
* **A share link**, a sanitised public copy: no cookies, no environment
  headers, no browser storage state, no console or network detail. Revocable,
  optionally expiring.
* **The API**: `GET /api/runs/{id}` returns the run with resolved artifact
  URLs.

## Retention and safety

Artifacts are stored in object storage and pruned according to your plan's
history retention. Run ids are UUIDs and share links are 128-bit tokens, so
neither can be guessed.

Cookies, browser storage state and environment cookies are encrypted at rest.
Password-like values are redacted before the run is stored at all. See
[Test data](/test-creation/test-data#redaction).


## Related topics

- [Debugging a failed run](/test-execution/debugging.md)
- [Core capabilities](/introduction/core-capabilities.md)
- [What is Testorim](/index.md)
- [Quickstart](/getting-started/quickstart.md)
- [Create a project](/getting-started/create-a-project.md)