# Investigate with session replay

> Use a browser recording, timeline markers, console, network, and errors without losing the customer context.

Canonical page: https://anectico.com/docs/investigate/session-replay/


Session replay shows what happened in the browser. Use it to understand the customer-visible steps
around an error, then follow the linked Issue and backend evidence instead of treating the recording
as the complete explanation.

## Find the right recording

Open **Analytics → Replays** and search by customer or session ID. Check the start time and duration
before opening a recording. When you begin from a customer timeline or Issue, prefer the replay
linked there because it already preserves the relevant person and failure context.

The customer page’s **Recorded replay** card shows the linked session and its recorded duration.
Select **View replay** to inspect the actual captured screen and interactions. The card does not
preview screen contents or indicate that a session is currently live.

The recording list belongs to the active project. If a known session is absent, confirm the project
before changing replay capture settings.

Product-analytics drill-downs point here. Every funnel or retention contribution event that carries
a session ID also reports whether that session has a recording — `available`, `none_recorded`, or
`withheld` when the credential you used has no `replay:read`. See
[Inspect one contribution](/docs/investigate/product-analytics#inspect-one-contribution).

Recording metadata and playback require the recording's project to still exist and be active.
Deleted projects are omitted from organization-wide recording lists, and direct reads of their
recordings return not found. If Anectico cannot verify the current project, the read is temporarily
unavailable; retry instead of treating this as evidence that no recording exists. The same check
applies through the dashboard, MCP and CLI. It does not require an additional `projects:read`
permission on your replay credential.

Deleting a project or organization also schedules asynchronous Replay cleanup. Cleanup removes
stored chunks, including chunks left without an index after interrupted uploads, before removing
recording metadata. Failed cleanup remains pending for retry. The deletion response confirms the
scope deletion; it does not confirm that all stored objects have already been removed.

## Read the timeline

Play the session once to understand the journey, then use the timeline markers to revisit failed
requests and captured errors. A marker is evidence that something happened at that time; it is not
by itself proof of the cause.

Use the panels below the player deliberately:

- **Console** shows browser console entries only when console capture was enabled.
- **Network** shows captured request activity and failed-request markers only when network capture
  was enabled.
- **Errors** shows errors related to the session and links grouped failures back to their Issue.

Select an entry to seek to its point in the recording. Use the **Person** link to return to the
customer story, and review **Events in this session** for meaningful application actions.
On a narrow screen, the player and context panels stack vertically and the recording stays within
the available page width, so use the same controls without horizontally scrolling the dashboard.

## Follow the backend evidence

A replay becomes much more useful when browser requests propagate W3C `traceparent` and trusted
identity context to an instrumented backend. From the related error or customer timeline, open the
trace and logs for the same moment. Keep the project, environment, and time window unchanged while
you compare them.

If the replay has missing chunks, treat the visible portion as incomplete. Network loss, page
termination, blocked uploads, or retention can create gaps; do not infer that an action did not
happen merely because it is not visible. Playback also checks that stored content matches the
accepted recording. Changed content is omitted as a gap; a recording without enough information
to verify its content is refused.

## Protect customer data

Replay is intentionally opt-in. Input masking is enabled by default. Console and network capture
are also enabled by default and can include sensitive application data — review what your
application logs and sends, and disable them if needed. Anectico cannot reconstruct data that was
masked in the browser.

If the player is empty, the wrong session is linked, or expected panels contain no data, see
[Replay or symbols are not working](/docs/help/replay-and-symbols).

- [Record session replay safely](/docs/instrument/session-replay)
- [Understand one customer's story](/docs/investigate/customer-story)

## Jump to recorded highlights

The replay player's **Highlights** tab lists recorded developer events and errors in
chronological order. Select a timestamp to seek the recording; linked errors and traces
open the underlying evidence. Highlights use the `recorded_events_v1` method: they describe
recorded signals, not an AI interpretation of the customer's intent or screen pixels.
Silence does not establish abandonment, success, or recovery.

Highlights return at most 50 moments and preserve the related-signal feed's incomplete-data
indicator. Missing/invalid timestamps, moments before the recording, and truncation make the
result partial. A readable session and `replay:content:read` are required. Current recording
retention applies on every read; there is no separate saved summary to outlive the evidence.

Agents can discover `get_replay_highlights` through `list_read_actions` and execute it with
`project_id` and `session_id`. CLI: `anectico replay highlights SESSION_ID`. REST:
`GET /api/v1/replay/{session_id}/highlights?project_id=PROJECT_ID`. Responses include the
method, summary, timestamps, offsets, Issue/trace references, and `partial`.