How can I see the user actions right before a frontend error (clicks/navigation) so I can reproduce it?
Application Observability

How can I see the user actions right before a frontend error (clicks/navigation) so I can reproduce it?

8 min read

In a perfect world, every bug comes with a step‑by‑step repro script. In reality, you usually get, “It just broke when I clicked something.” If you want to reliably see the user actions right before a frontend error—clicks, navigation, and UI changes—you’ll want to pair error monitoring with Session Replay so the error is tied directly to a video‑like reproduction of what actually happened.

Quick Answer: Use Sentry’s Session Replay alongside frontend Error Monitoring. Sentry captures the error, links it to a replay of the user’s session (clicks, navigation, inputs, page views), and lets you watch exactly what the user did before the frontend error, so you can reproduce and fix it faster.


The Quick Overview

  • What It Is: A way to automatically record user interactions (clicks, navigation, scrolls, inputs) as “replays” and link them directly to frontend errors and performance issues.
  • Who It Is For: Frontend and full‑stack developers, QA engineers, and SREs who need to reproduce flaky UI problems and JavaScript errors without guessing.
  • Core Problem Solved: “Can’t reproduce” issues—errors that only happen in production, on specific browsers/devices, and with very particular user flows.

How It Works

At a high level, you instrument your frontend with the Sentry SDK, enable Session Replay, and let Sentry do the rest. When a frontend error is thrown, Sentry captures it as an event, groups it into an issue, and (when available) attaches a replay of the user’s recent actions leading up to that error.

Under the hood, there are three main phases:

  1. Capture user session + interactions

    • The frontend SDK records a user session as a replay: page visits, clicks, taps, mouse movements, scrolls, and other DOM changes.
    • This replay is captured as a privacy‑aware stream of events, not a raw video file, so it’s searchable and linkable to errors and performance data.
    • You can configure what to mask or exclude (e.g., input fields, specific selectors) to honor privacy constraints.
  2. Link errors to replays

    • When an error/exception occurs, Sentry captures:
      • The error event (stack trace, release, environment, browser, OS).
      • The relevant replay that was active at that moment.
    • In the issue details in Sentry, you’ll see a “View Replay” link or panel, letting you jump straight from stack trace to the user’s journey.
  3. Debug and reproduce using the combined context

    • Open the Sentry issue, inspect the stack trace, tags, and breadcrumbs.
    • Click into the attached Session Replay.
      • Watch what the user did: the exact clicks, navigation path, and UI state that led to the frontend error.
      • Confirm timing: did the error fire immediately on click, after a route change, or when an async request completed?
    • Use that information to recreate the scenario locally and fix the bug.

In practice, the workflow looks like: “See a spike in a frontend error → open the issue → watch the replay → copy the relevant steps → reproduce locally → fix → deploy.”


Features & Benefits Breakdown

Core FeatureWhat It DoesPrimary Benefit
Session ReplayCaptures user sessions (page views, clicks, navigation, scrolls) as replayable timelines.Lets you see what the user did right before the error.
Error + Replay LinkingAutomatically associates frontend error events with the relevant replay session.No more guessing which actions triggered the error.
Deep Error ContextCaptures stack traces, environment, release, browser, device, and breadcrumbs with each error.Move from “it broke” to a code‑level root cause quickly.
Tracing & SpansTracks transactions and spans across frontend and backend services.Connect the UI action to backend latency or failures.
Session FilteringFilter replays by error type, URL, browser, user, or performance signals (e.g., long loads).Quickly find the one replay that actually matters.
Privacy ControlsMask inputs, redact DOM nodes, and control what’s recorded/stored.See the behavior while staying compliant and respectful.

Ideal Use Cases

  • Best for “works on my machine” frontend errors:
    Because it lets you watch the real production path—from the first page load to the click that triggered the error—rather than trying to recreate it from vague descriptions.

  • Best for complex navigation flows (SPAs, multi‑step wizards):
    Because Session Replay shows the full route changes, component transitions, and UI state changes, so you can see exactly where the flow breaks and why.


Limitations & Considerations

  • Not every issue needs a replay:
    You don’t need (or want) a replay for every trivial error. Use sampling controls to limit replays to certain environments (e.g., production only), URLs, or error types. That keeps costs predictable and cuts out noise.

  • Privacy and compliance constraints:
    You likely don’t want user PII or sensitive form data in your replays. Configure masking for inputs and sensitive fields, and work with your legal/security teams to define what’s recorded. Sentry supports data residency (US or Germany) and encrypts data at rest and in transit (AES‑256, TLS), but you still control what’s captured.


Pricing & Plans

Session Replay volume is metered separately from error events. A “replay” is a video‑like reproduction of a user interaction including page visits, mouse movements, clicks, taps, and scrolls on a site, web app, or mobile app.

You pick a base quota of monthly replays and can add usage as you grow:

  • Developer / Team plans:
    Good for small to mid‑sized teams who want to tie a subset of production errors to actual user behavior. Start with a modest replay quota, then adjust once you see how often you rely on video‑like debugging.

  • Business / Enterprise plans:
    Best for organizations that want broader coverage (multiple projects, teams, and environments), governance features (SAML + SCIM on Business+), and more control over quotas, data residency, and support. You can combine high replay volume with Error Monitoring, Tracing, Logs, and Profiling to build a unified debugging workflow.

Exact pricing and included quotas can change, so check the current details on Sentry’s pricing page or talk to Sales if you expect large replay volumes.


Frequently Asked Questions

How do I actually see user clicks and navigation before a frontend error in Sentry?

Short Answer: Enable Session Replay in your frontend Sentry SDK, then open an error issue and click the attached replay to watch the user’s session leading up to the error.

Details:
Once Session Replay is configured:

  1. A user hits your site/app, and the SDK starts a replay session.
  2. As they click, scroll, and navigate, Sentry records these interactions.
  3. When a frontend error occurs (e.g., an unhandled exception in your React component), the SDK sends an error event to Sentry.
  4. Sentry links that event to the active replay session.
  5. In the Sentry UI, you open the issue and see a “Replay” tab or button; click it to watch the timeline of actions, including:
    • Which page they were on.
    • What they clicked.
    • How the UI changed.
    • When the error popped.

From there, you can pause, scrub, or jump to the exact moment the error was thrown, then reproduce that flow in your local environment.


Can I control what user data Session Replay records?

Short Answer: Yes. You can mask fields, redact elements, and configure what’s captured so you don’t record sensitive data.

Details:
Sentry’s Session Replay is designed to be privacy‑aware:

  • Input masking: You can automatically mask all text inputs or only specific selectors (e.g., password, credit-card-number).
  • DOM redaction: Mark specific elements or regions of the page as “do not record” to completely exclude them from the replay.
  • Environment targeting: Restrict replays to specific environments (e.g., production and staging only) so you’re not recording local/dev sessions.
  • Data security: All data is encrypted at rest and in transit (AES‑256, TLS) and hosted on Google Cloud Platform, with SOC 2 Type II, ISO 27001, and HIPAA attestation available. You can choose US or Germany for data residency.

The net result: you see what you need to debug (clicks, navigation, UI changes) without exposing sensitive user data.


Summary

If you’re asking “How can I see the user actions right before a frontend error (clicks/navigation) so I can reproduce it?”, the practical answer is: connect your error monitoring to a reliable view of user behavior.

With Sentry:

  • The frontend SDK captures errors and their full context (stack traces, environment, releases).
  • Session Replay records user sessions and links them to those errors.
  • You open an issue, watch the replay, and turn a vague “it broke” report into a concrete, step‑by‑step reproduction that leads directly to a fix.

No guesswork, no “cannot reproduce” back‑and‑forth—just a clear path from user action to code change.


Next Step

Get Started