How Error Tracking and Session Replay Work Together
Error tracking tells you what broke. Session replay shows the user path that led there. Here is how the two tools connect—and why production debugging needs both.
Production bugs rarely arrive with clean repro steps. A user reports that checkout broke. Your error tracker shows a TypeError on line 847. You still do not know whether they hit the back button, skipped a field, or lost network mid-submit. Error tracking and session replay solve different halves of the same problem—and work best when they share one timeline.
Error monitoring answers what failed: exception type, stack trace, release, browser, frequency. Session replay answers what the user did in the minutes before and after: clicks, scrolls, route changes, failed requests, console output. Linked together, you debug production issues with evidence instead of guesswork.
What each tool actually gives you
Error tracking: signal at scale
Error tracking watches your application in production, groups duplicate failures, and alerts the team when something new spikes. You get structured data—file, line, breadcrumbs, user ID, environment—that scales across thousands of sessions.
What it does not give you is visual context. A stack trace on cart.total being undefined does not tell you the user opened checkout in two tabs, abandoned the first, and returned via the browser back button. That navigation pattern is invisible in the exception alone.
Session replay: context you can watch
Session replay records a DOM-based playback of the user's session—not a screen recording, but a reconstruction of page state and interactions synchronized with network and console activity. Sentry's documentation puts it plainly: stack traces tell you what broke; replay shows you how it broke.
Replay is heavier than error capture. Teams typically sample a fraction of all sessions and capture replays for every error (replaysOnErrorSampleRate: 1.0 is a common production default). The recorder buffers roughly sixty seconds of activity before an error fires, so you see the lead-up even when you are not recording full sessions.
How the two connect in practice
The integration point is the error event. When an exception fires during a recorded session, the monitoring platform attaches the replay ID to the issue. You open one grouped error and click through to the session—no manual correlation, no asking the user for a screen share.
That handoff changes triage speed. Support forwards a vague ticket. Engineering opens the issue, reads the stack trace, and scrubs the replay timeline to the error marker. The fix often becomes obvious: a race on submit, a stale cache after navigation, a validation message the user never saw.
Full-stack context
Frontend-only debugging is not enough when the failure is a 500 from your API. Sentry's backend error linking connects frontend replays to server-side errors through distributed tracing. You watch the user click "Pay," see the request fail in the replay timeline, and jump to the backend trace for the same request ID. Error tracking on the server gives you the exception; replay gives you the user impact; tracing ties the wire between them.
That is what full stack context means in practice—not two dashboards that never meet, but one investigation path from user action to server failure.
Error tracking vs session replay
| Dimension | Error tracking | Session replay | | --- | --- | --- | | Primary question | What broke, where, how often? | What did the user do before it broke? | | Data shape | Stack traces, grouping, alerts | Timeline playback, DOM state, interactions | | Volume | Every captured exception | Sampled sessions; often 100% on error | | Best for | Regression detection, prioritization | Reproducing edge cases, UX failures | | Weak alone | Cannot show invisible user paths | No automatic grouping or alerting | | Together | Issue record with linked evidence | Replay attached to the same issue |
Neither tool replaces the other. They sit at different points in the debugging lifecycle and answer complementary questions.
A workflow that uses both
When you wire error tracking and replay into the same pipeline, triage follows a repeatable sequence:
- Capture — SDK or browser extension records errors and replays in production with privacy masking enabled.
- Group — Duplicate exceptions collapse into one issue with occurrence count and affected users.
- Replay — Open the linked session; scrub to the error timestamp and watch the preceding minute.
- Trace — If the failure is API-bound, follow the request from replay into backend logs or traces.
- Ticket — File or auto-create a work item with stack trace, replay link, and environment metadata attached.
- Verify — After deploy, confirm the error rate drops and spot-check a replay on the fixed flow.
Steps three and five are where most teams lose time when the tools live in separate products. Copying replay URLs into Jira, re-finding the session after the issue ID changes, or debating whether the stack trace is enough—the friction adds hours per bug.
Where a unified platform fits
Point solutions for errors, replay, and issue tracking each work. The cost shows up in handoffs. A unified QA platform keeps capture, replay, and the issue board in one place so the workflow above does not break at the ticket step.
Optics is built around that loop: production errors surface automatically, replays attach to the issue, and the ticket lands on your board with full context—no paste step, no lost repro. If you are evaluating tooling, compare how each vendor handles the link between error and replay, not just the feature checkboxes. Our docs cover SDK setup, masking rules, and extension-based capture for teams that want evidence on every report.
What to implement first
If you are starting from zero, enable error tracking first. You need grouping and alerts before replay volume matters. Add session replay second, with error-only sampling so every new exception carries context without recording every visitor.
If you already have error monitoring but engineers still ask "can you reproduce this?", replay is the missing half. If you have replay but no structured issue flow, you will watch sessions and still lose fixes in the backlog.
Either way, the goal is the same: debug production bugs with the full picture—exception data plus user evidence—in one investigation, not three tabs and a Slack thread. Learn more about who we are and pricing when you are ready to run both in a single workflow.
FAQ
Do I need both error tracking and session replay?
For production bugs you cannot reproduce locally, yes. Error tracking surfaces failures automatically with stack traces and grouping. Session replay adds the user context—clicks, navigation, network calls—that explains why the failure happened. One without the other leaves a gap in your debugging workflow.
Does session replay replace error monitoring?
No. Replay captures what the user did; it does not replace exception capture, alerting, or issue grouping. Most teams run replay at a lower sample rate than error capture and link replays to error events so you open one issue and jump straight to the session.
How are replays linked to errors?
When both run in the same session, the monitoring SDK associates the error event with the active replay. On error-only sampling, the recorder typically buffers the minute before the exception and continues recording afterward. You land on a stack trace with a replay attached—not a separate hunt through session lists.
What about privacy when recording sessions?
Reputable replay tools mask text inputs, block sensitive media, and let you exclude DOM nodes by selector. Error tracking already strips or hashes PII in many setups; replay needs the same discipline. Check your vendor's masking defaults before you ship to production.
How much overhead does running both add?
Error capture is lightweight relative to replay. Replay cost scales with session volume and retention, which is why teams sample general traffic heavily and capture replays on every error. See our pricing page for how Optics bundles both without per-session billing surprises.