Frontend monitoring vs session replay.

The one-sentence answer

Frontend monitoring (also called Real User Monitoring or RUM) aggregates errors + performance metrics + breadcrumb events across all users. Session replay captures the full reconstructable session — DOM, network, console, user inputs — for an individual user. Monitoring tells you what broke and how often; replay shows you what the user saw when it broke.

What each one captures

The technical surface area differs substantially:

When monitoring wins

Frontend monitoring is the better fit when:

• <strong>You need cross-user aggregates.</strong> "How many users hit this error this week?" Monitoring is built for this; replay isn't.
• <strong>You need Web Vitals dashboards.</strong> LCP/INP/CLS trend lines across releases; monitoring is the right tool.
• <strong>You need release-health correlation.</strong> Crash-free-sessions percentage per release tag; this is monitoring's sweet spot.
• <strong>Storage volume is a hard constraint.</strong> Monitoring captures ~5-50 KB per session (depending on breadcrumb depth); replay is ~30 KB per session (DOM-only) or more if you keep long flows.

When replay wins

Session replay is the better fit when:

• <strong>You need to see what the user saw.</strong> Stack trace alone can't tell you whether the button was visible, whether the form was filled, whether a modal was blocking the click. The DOM at-the-moment-of-the-error is the only ground truth.
• <strong>You need to debug silent failures.</strong> No error fired but the user left — monitoring has no signal; replay does.
• <strong>You're drafting bug tickets.</strong> A ticket with "user clicked Add to Cart and nothing happened, replay link below" is actionable; "uncaught TypeError at line 42" requires the engineer to imagine the context.
• <strong>You're generating tests.</strong> Replay captures the action sequence Playwright needs; monitoring captures breadcrumbs that aren't reconstructable into a runnable spec.

Why most teams run both

The two tools answer different questions in the same workflow:

• <strong>Monitoring: "what is broken?"</strong> Aggregates show 147 users hit a 500 error on /checkout this week.
• <strong>Replay: "what does broken look like to the user?"</strong> Click a session from the aggregate, watch the replay, see the half-rendered confirmation page.
• <strong>Loop closes: "is the fix shipped?"</strong> Monitoring tracks the error rate over time after deploy; replay confirms no new edge cases.

Wiring them together: shared session IDs

The pattern most teams converge on: capture the same session ID in both tools, so a Sentry exception view links directly to the Relyv replay of that session. Implementation is a few lines:

// One init that tags Sentry events with the Relyv session ID
import * as Sentry from '@sentry/browser';
import { init as initRelyv, getSessionId } from '@relyv/sdk';

initRelyv({ apiKey, projectId });
Sentry.init({
  dsn,
  beforeSend: (event) => ({
    ...event,
    tags: { ...event.tags, relyv_session_id: getSessionId() },
  }),
});

What about Sentry Replay specifically?

Sentry has its own session-replay product bolted onto the error-monitoring core. If you're already on Sentry and want replay attached to exceptions, it's the lowest-friction path. Trade-offs: requires Sentry subscription (no standalone), less mature than the dedicated replay tools on cross-session intelligence + AI workflows + test generation. Standalone tools like Relyv work alongside Sentry via the shared-session-ID pattern above without requiring you to leave Sentry.