Session Explorer

Use Session Explorer to browse, filter, and replay real user sessions. This page documents the Sessions list and the Session Player (replay) with Events, Network, and Attributes tabs, along with practical workflows, setup notes, and troubleshooting.

Purpose

• Support & triage: reproduce what a user saw, including their clicks, views, and network calls.
• Performance analysis: correlate web vitals, long tasks, and third‑party scripts with perceived slowness.
• Release validation: verify that a new version doesn’t introduce errors or frustration.

Access & Scope

Real User Monitoring → Applications → Session Explorer

The time range selector (top‑right) controls what the page shows. Auto‑refresh is enabled; click Pause to freeze the view while investigating.

Filters (left rail)

Use facets to narrow results quickly. All widgets on the page respect your selection.

• App Version – focus on a specific build (e.g., during a rollout/canary).
• ENV – filter by environment (e.g., prod, staging).
• error.type – sessions that contain a given client‑side error category (e.g., documentError).
• Page – sessions that visited a particular route (e.g., /blog/...).
• service.name – filter by service when present.
• User Email / User Name – available if you identify users in the SDK init.
• Quick Filter – search facet values (great for long page lists).
  

Tip: Start broad → set ENV → add App Version → sort the sessions table by Error Count or Frustration Count to choose the best replays to watch first.

Sessions List (Dashboard)

The Sessions list gives you a real‑time pulse and a detailed table of recent sessions.

Trend

A line chart (Session Trend) shows the count of active sessions across the selected time range so you can see traffic waves and correlate them with incidents.

Table Columns

Each row represents one session. The default columns are:

• Time Created – when the session started.
• Last Updated – timestamp of the most recent event recorded in the session.
• Visitor Info – country flag + OS and browser icons inferred from the user agent.
• Trace Time Spent – cumulative traced time captured inside the session window.
• Visitor – user label; shows Anonymous unless you set identity in the SDK.
• Action Count – number of user actions detected (clicks, route changes, etc.).
• Error Count – total front‑end errors captured in this session.
• View Count – number of page views.
• Frustration Count – sum of frustration signals (e.g., rage/dead clicks) associated with the session.

Click any row to open the Session Player. Use column headers to sort; combine with filters to create ad‑hoc views (e.g., “prod, latest version, sort by errors”).

Session Player (Replay)

The player reconstructs what the user saw and did. It renders the DOM timeline and overlays instrumentation so you can inspect behavior precisely.

Player Controls

• Playback bar – shows current time and total duration.
• Speed – change playback rate (e.g., 1× to 4×).
• Skip Inactive – automatically jump past idle periods to speed up review.
• Engage Mode – toggle to interact with the replay (inspect elements, hover tooltips, etc.).
• Share – copy a link to collaborate with teammates.
• Console panel – filter log types (Info, Debug, Warn, Error, Network Error), wrap text, and auto‑scroll.

Tabs

1) Events Time‑ordered event stream.

Common items include:

• documentLoad (page load)
• webvitals (FCP/LCP/INP/CLS events)
• longtask (main‑thread blocks) with route context
• User actions (clicks, navigation)
• Network events (e.g., HTTP GET/POST …, Type: Fetch)

Use it for: pinpointing what happened around a failure or slowdown—e.g., a long task right before a click appears unresponsive.

2) Network Table of captured requests with Name (URL), Status (e.g., 200/204/0), and Method. Open a row to view details when available.

Use it for: finding failing calls, blocked requests (status 0), or unusually slow endpoints in the exact moment the user experienced them.

3) Attributes

Contextual metadata grouped for quick scanning:

• Application – Environment, Application Version, SDK Version.
• Session – Time Spent, Session ID.
• GEO – Continent, Country, City.
• Device – Device Type, OS Type, OS Version (when available).
• Browser – Name and Version.
• Other Attributes – e.g., Session Recording Available, Telemetry SDK Language (webjs), Telemetry SDK Name (opentelemetry).

Use it for: reliably reproducing conditions (OS/Browser/Geo/ENV) and linking a replay back to a specific build via Application Version.

Workflows (Step‑by‑Step)

Investigate a User‑reported Bug

1. In Session Explorer, filter by Page or User Email (if you capture identity).
2. Sort by Error Count; open a top session.
3. Toggle Skip Inactive and play at 2×.
4. In Events, look for longtask/webvitals near the time of the complaint.
5. Switch to Network; check non‑2xx or high‑latency calls that align with the issue.
6. Use Attributes to record device/OS/browser.
7. Click Share and attach the link to the ticket.

Validate a Performance Regression after Deploy

1. Filter App Version to the new build and ENV = prod.
2. Scan the table for sessions with high Frustration Count or Action Count but low responsiveness.
3. Replay and correlate longtask events with Network calls.
4. Capture Session ID and example timestamps for the fix/PR description.

Triage Intermittent Network Failures

1. Leave filters broad, open a few recent sessions.
2. On Network, sort by Status and investigate 0, 4xx, 5xx.
3. Use the Console panel with Network Error enabled to surface JS exceptions around the same time.

Troubleshooting

• Nothing appears in the player → check CSP/ad‑block rules for the recording endpoints; ensure the SDK initializes early in the page.
• No sessions for a new version → confirm app.version is set and the build is deployed to users.
• Status = 0 in Network tab → typically indicates a blocked request or connectivity issue; verify CORS and ad‑block filters.
• High Frustration Count but few errors → look for longtask spikes or slow third‑party scripts in Events.

Privacy & Governance

• Use masking options to ensure PII and sensitive inputs are not captured in recordings.
• Limit recording on privileged/admin routes if necessary.
• Share session links only with authorized teammates; replays include the DOM and may reveal user content that wasn’t masked.