# Open the session viewer

Canonical: https://fairleadhq.com/docs/recorder/session-viewer/

Updated: 2026-10-10
Publication state: published
Product version: Recorder source f6ed5b96

Agent summary: Use each viewer as a different angle on one recording, follow linked evidence, and preserve your findings. The viewer is a snapshot; reset clears local evidence; its URL is not shareable.

## Prerequisites

- A stopped local recording

## Inputs

- Recorded actions and diagnostic evidence

## Outputs

- A reviewed session

## Limitations

- The viewer is a snapshot; reset clears local evidence; its URL is not shareable

## Permissions

- Access to the local recording

## Privacy

- Review captured content before sharing


Use each viewer as a different angle on one recording, follow linked evidence, and preserve your findings.

Open the session viewer to connect what happened on screen with the actions and data behind it. Follow the evidence until you can explain the result or name the next check. Local review works without a Fairlead account.

## Open the recording

1. Select **Stop recording** when your check is complete.
2. Select **Investigate** in the side panel.

Recorder opens an extension tab for the session, or focuses its existing viewer. The side panel may close as review moves to the new tab.

## Choose the evidence

The viewer shows the same recording from different angles. Start from a known symptom, action, or error and follow the connections that answer your question. For example: **image of wrong state → action that should change it → submitted value → returned state → note explaining the discrepancy**. This is a reading path, not a mandatory tab order.

The viewer opens on **Overview** when it detects failed requests, warning/error logs, or locator risks; otherwise on **Actions**. Overview's metrics open the corresponding evidence. Its checklist and readiness text help organize review; they do not decide whether the application behaved correctly. A silent data defect can have no flagged errors.

| View | Question it helps answer | What to do with the answer |
| --- | --- | --- |
| **Actions → Recorded Actions** | What did the user try, and what changed around that action? | Select an action, inspect its target/state, and open its requests, logs, or screenshots. Identify the first discrepancy. |
| **Actions → Event Log** | Which captured events make up that interaction? | Inspect technical event types and times when keyboard actions, repeated clicks, or navigation need explanation. One user step can produce several events. |
| **Screenshots & Attachments** | What was actually visible? | Open the image, confirm identity and context, then attach an observation to it. Compare before/after images when available. |
| **Network** | Did the intended data leave the browser, and what came back? | Compare the same record across a write and following read, or across successive updates. Include requests without an action link. |
| **Console** | Did page code or the browser report something relevant? | Inspect message, stack, source and available arguments; connect the log to the same operation and time before treating it as a lead. |
| **Timeline** | In what order did actions, requests, page events, logs and images occur? | Check whether the proposed explanation fits the sequence; open any event's detail without leaving the chronology. |
| **Environment** | Which captured conditions could explain a difference between attempts? | Compare browser, viewport/zoom, language, colour scheme and connection context. Add the application build, role and settings yourself. |
| **Notes** | Which observations have survived the investigation? | Revisit pins, verify sources, write explanations and identify the decisive findings. |
| **Description** | Can another person follow the result without repeating my investigation? | Read the session type, lookup and result context; assemble minimal steps, expected/actual, evidence and open questions. |
| **Tests** | Can the captured actions help reproduce this later? | Review script and locator risks, then give a developer the expected checks that need assertions. Viewing a script does not execute a test. |
| **Privacy preview** | What will be shared, and which gaps or privacy choices affect the evidence? | Follow entries back to their sources, inspect the export decisions, and preserve a truthful account of missing evidence. |

## Read an action as intent, state, and related activity

In **Actions → Recorded Actions**, select the action nearest the result you are investigating. Read the available detail sections in this order:

1. **Target** identifies the actual control: visible text, label, role, element, selector, frame and available group context. Use these to distinguish repeated buttons or the same label in different rows. A readable label is a clue; check the subject rather than assuming the label uniquely identifies it.
2. **Captured value** and **What changed** show recorded input and before/after control changes. If you intended to check a box, this is stronger evidence than a click alone. It still does not prove the application saved that value.
3. **Element & form state** supplies captured state such as disabled, read-only, busy or form validity when available. This helps investigate “clicked but nothing happened.” An absent field does not mean the state was false.
4. **Page changes** describes captured DOM reaction; **URL changed** gives the recorded destination or query change. Use these to see whether the page reacted or changed context. A DOM change count cannot tell you whether the business result is correct.
5. **Related activity**, the request/log counts, and screenshot counts connect the action to other evidence. Select a request or log to open its details beside the action. Use its **Open in Network tab** or **Open in Console tab** arrow when the question needs the wider stream.

A **Clicked image** thumbnail identifies an image target; it is different from a captured screenshot of the page. Screenshot association is based on time and needs the same identity/context check as a request association.

**Cause** on a request or an associated console entry leads back to a likely action. **Back** in the viewer header returns to the previous view after supported evidence navigation. **View evidence** in Notes returns to the saved source. These routes let you examine one fact from another angle without rebuilding the whole investigation. Associations can be inferred from timing, so verify the record, operation and sequence yourself.

For keyboard investigations, turn **Key actions only** off; it hides keydown events. Event Log also hides scroll events by default. When evidence seems absent, inspect the broader view before concluding it was not captured.

If repeated generic action names make the sequence hard to follow, use **Rename** in a local action's detail, write a short purpose such as `Move affected card to In progress`, and **Save**. The original narrative remains visible; Event Log and Tests retain the captured data. Names also help when inserting recorded actions or notes into Description. Use **Restore** to return to the original name. To shorten the final reproduction, edit the inserted description: **Delete action** permanently removes the action and its notes from the recording and exports.

## Read a request as one part of an operation

Select an HTTP request from Actions, Network, Timeline or a saved note. The same detail views serve different questions:

| Detail | Inspect when… | Decision it supports |
| --- | --- | --- |
| **Headers** | You need to confirm destination, method, status, content type, request/response headers, or recorded failure information. | Is this the intended operation? Was it canceled, blocked, redirected, or served from a recorded cache source? HTTP success alone does not establish correct data. |
| **Payload** | You need the sent record ID, changed value, body or query parameters. | Did the browser express the user's intent? An omitted property raises a contract question; it does not establish which layer should supply it. |
| **Response** | You need the returned data or application error. | Did the result match the request and expectation? A short acknowledgement may require inspecting a subsequent read. GraphQL errors can accompany HTTP 200. |
| **Initiator** | You need the available script/stack origin to help a developer locate the request path. | Preserve the useful frame or function context, keeping the UI's **inferred** qualification. It is not a server trace. |
| **Timing** | You need start, end, duration, request phases, or linked browser resource timing. | Did the request finish before the wrong state was captured? Is the delay within the request or still visible afterwards? Missing phases are not zero durations. |
| **Cookies** | Login/session behavior may differ between attempts. | Compare recorded request/response cookie presence and attributes. Header links lead here; a masked value is not an absent cookie. |
| **EventStream**, when present | The page receives server-sent updates after the HTTP response begins. | Compare event time, identity and data with the visible update; the initial HTTP status does not describe every later message. |

A WebSocket row instead shows captured messages with direction and time. Read them when a live update may explain a state change without another HTTP response. Preserve a relevant safe excerpt and its time in your description; this view has no frame-note control, and standard local downloads do not include WebSocket frames.

Identify repeated requests by time and record, not URL alone. When a body is unavailable, read the displayed reason. Truncated, redacted and uncaptured content are different gaps. **Load from cache** and **Re-download image**, when offered for an image response, retrieve an image later; record that later provenance instead of treating it as a screenshot of the original failure.

## Check chronology and conditions

Use **Timeline** to ask “could these events explain each other?” It includes captured lifecycle and performance events as well as actions, requests, logs and screenshots. Open a lifecycle entry to inspect the navigation, frame, visibility or viewport context available for that event. Open a long task or paint/resource entry for its recorded timing and attribution.

A request row is positioned at its **start**, not completion. Check its **Timing** end before claiming a screenshot follows the response. Linked browser resource timing can appear inside that request's Timing tab rather than as a duplicate Timeline row. Copy a useful standalone performance/lifecycle observation into an action note or Description; those standalone details have no note editor of their own.

**Environment** describes initial conditions and the document open when recording began. Its document load may precede Start, and its connection tier is a browser estimate. Neither measures the time taken by a later click. Use a [focused responsiveness investigation](https://fairleadhq.com/docs/recorder/slow-or-unresponsive/) when those distinctions matter.

## Preserve the reasoning, then prepare the handoff

Right-click a useful field → **Pin** while following a lead. Later, select it in **Notes**, choose **Add comment**, explain what it shows and why it matters, and **Save comment**. Use **View evidence** to check the target and surrounding data. Notes on an action, field and screenshot answer different questions; combine them into a short explanation rather than repeating the same sentence on each. See the [worked investigation](https://fairleadhq.com/docs/recorder/bug-reporting/#find-the-deciding-evidence).

Use **Description → Add → Notes** after the comments are final. The inserted text includes source context, but is a copy and does not follow later note edits. Above the editor, Recorder shows available session context: Explore, Test case, or Verify fix; the issue/test-case lookup; and a selected result. Add preconditions and expected/actual behavior yourself. Older stored reports can contain a separate legacy reproduction-notes value, but the current local editor uses Description.

Open **Tests** when the action sequence is worth reusing. In the Playwright preview, select a highlighted line or **Review locator** card to inspect its recommendation and **Technical locator details**. Locator risks concern repeatability; they are not proof that the original action failed. A generated script still needs setup and assertions for the result your notes describe. Puppeteer is available when generated; full downloads also include DevTools Recorder steps.

In **Privacy preview**, use the source ledger to separate **Policy rules**, **Your decisions**, and **Not sanitized** content. The ledger shows value and record counts plus what is hidden or visible in the export. A changed value can appear under both its rule and your decision, so do not add the rows into one total.

Select a rule or decision to inspect its values and affected records. Open a record to see its export JSON with treated paths marked, or follow **Show in Network / Actions / Console** to the exact evidence. Search and treatment/field chips narrow every level and show per-source match counts. **Screenshots**, **Truncated bodies**, and **Recording composition** expose image, completeness, and unsupported-field gaps. The **Originals** display toggle still changes local display/search rather than export decisions. See [review before sharing](https://fairleadhq.com/docs/recorder/review-redaction/).

For a local/new report, edit the header title and press Enter to save. Keep an existing connected issue's fetched title unless you intend to rename it. Use **Download** to preserve reviewed files, or the configured issue action for connected handoff. Check the resulting files/text/attachments before resetting.

## Return to the application

Select **Return to recording** to return to the recording context. You can also select the application's tab and open the Recorder side panel from the toolbar. Returning does not resume a stopped recording.

## Preserve the session

The viewer loads a snapshot of the stopped report. Saved notes, session details, and supported review changes update the local view, but it is not a live recording stream. Reload after attachment changes made elsewhere before downloading.

[Download evidence](https://fairleadhq.com/docs/recorder/bundle-contents/) before selecting **New recording**. Reset clears the local session and its open viewers; the viewer URL is not a shareable report link.

If the viewer is empty, confirm a local recording is still available. Missing attachment or test-preview data can affect those sections while the rest of the report remains readable. For a session opened from Control Plane, see [Open a stored session](https://fairleadhq.com/docs/recorder/stored-sessions/).