Session Explorer

Real User Monitoring gives you two surfaces for session work, and you move between them constantly:

• Session Explorer — the list. Filter and sort every session in the time range to find the ones worth watching.
• Session Inspector — the full-page debugger for a single session. The recording, a five-lane timeline, and the event, console, network and action streams all share one clock.

Clicking any row in the Explorer opens that session in the Inspector.

Purpose#

• Support and triage — reproduce exactly what a user saw, including clicks, screen changes, and network calls.
• Performance analysis — line up web vitals, long tasks, and third-party scripts against perceived slowness.
• Release validation — confirm a new build introduces no new errors or frustration.

Access and scope#

Navigate to Real User Monitoring → Applications → your application. Session Explorer is the default tab.

The application view carries five tabs: Session Explorer, Product Analytics, Performance Monitor, Error Tracking, and Heatmap.

The time range selector in the top-right controls everything on the page. Live mode supports ranges of one hour or shorter — for anything longer, use Update to refresh.

Use the search bar (Filter/Search by name, tag, label or annotation) for free-text search across sessions.

Filters (left rail)#

Facets narrow the list, and every widget on the page respects your selection. Counts come from the per-session dataset, so they reflect real session totals rather than a sampled fraction.

The Core, Browser, and OS groups are expanded by default; the rest expand on click. Each group has a search box for long value lists, and facets can be pinned to Favorites.

Sessions list#

Session Trend#

A time series (Session Trend) plots the Session Count across the selected range, so traffic waves line up against incidents. The sum of its buckets is what the list header reports as Total Sessions.

Table columns#

Each row is one session. These columns are shown by default:

More columns are available from the column selector:

The list sorts by Last Updated descending by default and loads more rows as you scroll. Column widths you drag are remembered per table.

Click any row to open the session in the Inspector. Filters you have applied travel with you, so the session switcher inside the Inspector holds the same population you were just looking at.

Session Inspector#

The Inspector is a full page of its own, at:

1/real-user-monitoring/{application}/session/{sessionId}

It is laid out in three regions:

• Left — the recording. The session replay, with the page URL above it and a session summary beneath.
• Right — the streams. Events, Console, Network, Actions, and Test Helper.
• Below — the timeline. Five lanes and the only transport controls on the page.

Drag the divider between the recording and the streams to rebalance them; the position is remembered for your next visit.

Header#

The header identifies the session and lets you move through the list without going back:

• Back to sessions returns to the Explorer.
• The session ID, followed by chips for the application, environment, session length, and either N errors or no errors.
• Badges for the user, browser, OS, and country.
• A stepper showing N of M with Previous session ( [ ) and Next session ( ] ).
• A shortcuts button opening the keyboard cheat sheet.

Session switcher#

The switcher is the page's sidebar. It collapses to a narrow rail labelled Sessions with a count, so the recording keeps the width until you ask for the list. Expand it to search (Search people or IDs…) and to see each session's user, country, browser, OS, action count, and pages viewed. The session you are watching is highlighted.

Session info#

Beneath the recording, a summary line carries the user's name (or Anonymous), country, browser, OS, application, and session length. Show Details expands three groups:

Timeline#

The timeline is the heart of the Inspector — five lanes over a single time axis and a single playhead, so when did it break, and what else was happening then reads at a glance:

Click any marker to jump the replay to that moment. On the scrub bar: click to seek, drag out a range to zoom the lanes, double-click to fit. Scrolling zooms around the pointer.

Transport controls#

The replay pane itself carries only a browser-chrome strip — the page URL the user was on at the current moment — and a fullscreen button (F; Space, ← and → keep working in fullscreen). Every other control lives on the timeline.

Tabs#

Each tab is a filtered view onto the same clock, so switching never loses your place. Tab badges carry session-wide counts and turn red when the tab holds an error. Each tab loads the first 100 rows of its stream, so on a busy session the badge can legitimately be higher than the number of rows you can scroll through.

Events — the session's activity: every root span, plus every error wherever it occurred, the document load, mobile app start, and every resource the page pulled in. Filter with the search box (Filter events…) or the quick filters: All activity, Screen changes, Errors, User activity, Network, Web Vitals. Stretches of dead air appear as their own row — 12.4s of no activity with a Skip ahead link — so a stall reads as a stall rather than as two adjacent events.

Console — console output at log, info, warn, debug, and error, filterable by level. When a session produced none, it reads No console output in this session.

Network — every fetch, xhr, resource, and websocket request, in a table of Name, Status, Method, Type, Size, Time, and a Waterfall bar scaled to the slowest request in view. Narrow it with the search box (Search & filter network), the type dropdown, or the Errors Only checkbox. A minimap above the table plots requests over the session: drag out a range to filter the table, drag the window to pan, double-click to fit. Selecting a request seeks the replay to it and opens a DevTools-style detail pane:

Selecting a request opens the detail pane beneath it, with the replay seeked to that request:

Actions — what the user actually did, with Rage click and Dead click flags called out. Filter by element or text, or narrow to Flagged only to jump straight to frustration.

Test Helper — generates a runnable browser test from the recording's own events, so it reproduces the real interaction sequence rather than a reconstruction. Choose Playwright, Cypress, Puppeteer, or Selenium, then Copy test. It needs a session replay to work.

Expanding a row#

Every row in Events, Console, and Actions expands in place, and what you get depends on the row:

• An error expands to its stack trace, with a Minified / Original toggle. Original resolves the frames through the source maps you have uploaded for that app.version; when no map is available it falls back to the recorded frames rather than showing nothing.
• Anything else expands to a mini trace — how long it took, how many spans it produced, and which services were involved. This is where a front-end event connects to the backend work behind it. If the trace never reached your services it says No backend spans were recorded for this trace.

The trace card also breaks the time down under Time by service, so you can see which service held the request.

Clicking a row seeks the replay to that moment; Open full error or Open full trace on the expanded card raises the detail drawer.

Detail drawer#

The drawer overlays the bottom of the page rather than displacing it, so the recording and timeline never move. Drag its top edge to resize, or expand it to full height.

• An error opens Error Details — the stack, source-mapped where you have uploaded source maps, with the occurrence and its context — alongside Related Sessions, the other sessions that hit the same error.
• Any other span opens the APM span panel: Trace, Trace Attributes, Events, and Logs, plus Headers, Request, and Response for network spans.

Inside the drawer, Error Details carries the occurrence and its context — affected users, instances, first and last seen, the spans leading up to the throw and downstream of it, the full attribute set, and an impact breakdown by version, device, screen, and country:

A span opens the same drawer onto the trace, with Waterfall, Flame Graph, Spans, and Map views:

Keyboard shortcuts#

Press ? at any time to open the in-app cheat sheet.

Sharing a moment#

The Inspector URL is shareable as-is. Append ?t= with an offset in milliseconds to drop the recipient at a specific moment:

1/real-user-monitoring/my-app/session/019780807f0058f052763f8493085e?t=45000

Links shared before the Inspector became its own page — the older ?sessionId= and ?timestampToJumpVideo= form — redirect automatically.

Workflows#

Investigate a user-reported bug#

1. In Session Explorer, filter by root.url or email.
2. Sort by Error Count and open a top session.
3. In the Inspector, press N to jump to the first error.
4. Read the Errors lane for what else happened at that instant.
5. Open the error to get the source-mapped stack, then check Related Sessions to see whether it is widespread.
6. Copy the URL — add ?t= at the failure — and attach it to the ticket.

Validate a release#

1. Filter app.version to the new build and env to prod.
2. Add the Frustration Count column and sort by it.
3. Open a high-frustration session and switch to Actions, filtered to Flagged only.
4. Cross-check rage clicks against the Network lane for slow or failed calls underneath them.

Triage intermittent network failures#

1. Open a few recent sessions and go to the Network tab.
2. Tick Errors Only to keep just the failures, or narrow by type to isolate fetch and xhr calls.
3. Open a failing request and read Timing — a long Waiting (TTFB) points at the backend, a long DNS lookup or Initial connection at the client or network.
4. Use the Console tab to catch exceptions thrown in the same window.

Turn a bug into a regression test#

1. Open the session that reproduces the defect.
2. Go to Test Helper, pick your framework, and Copy test.
3. Trim the generated script to the failing path and commit it.

Troubleshooting#

Privacy and governance#

• Mask PII and sensitive inputs so they are never captured — see Session Recording Privacy.
• Consider disabling recording on privileged or admin routes.
• Share session links only with authorized teammates. A replay reproduces the DOM and may reveal user content that was not masked.
• For retention and handling, see Data Security.