On-Demand Session Replay vs. Always-On Recording: Which Is Better for Debugging?

When a user reports that a checkout button failed, a page froze, or an error appeared exactly once and never again, logs alone rarely tell the whole story. You need to know what the user saw, which actions they took, what the browser requested, and what happened in the seconds before the failure.

That's what session replay is for. But underneath every replay tool sits one architectural decision that shapes everything else: does your application record every session all the time, or does it capture a session only when someone needs to investigate a problem?

Always-on recording gives you broad visibility and automatic coverage. On-demand recording takes a targeted approach, activating diagnostics for a specific user, workflow, or investigation. The right choice depends on your debugging goals, traffic volume, privacy requirements, and how much client-side overhead you're willing to carry on every page load.

What Is Always-On Session Replay?

Always-on session replay records user interactions across your application by default. A browser script loads for most or all visitors, observes page activity, and ships replay data to a platform for later review. Depending on the tool, that data may include DOM changes, clicks, navigation, console output, network activity, and other browser events.

The main advantage is coverage. When a problem is reported after the fact, there's a good chance a recording already exists. Product and support teams can also explore how users move through a workflow without first reproducing the issue — which is why most of the well-known tools in this space, from FullStory to Hotjar, are built this way.

That convenience comes with tradeoffs:

• The recording script runs during normal application use, for every visitor.
• Events and DOM changes create ongoing network and storage costs.
• Masking and privacy controls have to be configured carefully, everywhere.
• Large volumes of recordings make it harder to find the few sessions that matter.
• Retention, indexing, and access control become permanent operational concerns.

Always-on recording is a strong fit for product analytics and broad behavioral analysis. For engineering diagnostics, though, it usually captures far more data than a team needs to fix a particular bug.

What Is On-Demand Session Replay?

On-demand session replay captures a session when there's a specific reason to investigate it. A support agent sends a customer a magic link. A customer clicks a support widget and starts a recorded session themselves. A QA tester opens a diagnostic session while reproducing a regression.

The captured session still includes everything you need to debug the issue: DOM activity, console errors with stack traces, network requests and responses, navigation events, and masked inputs. The difference is that instead of recording every visitor indefinitely, you collect a focused diagnostic artifact tied to a known problem.

This model works especially well for teams that already run error monitoring, logs, and a ticket queue. Those systems tell you where to look; an on-demand replay shows you what actually happened in the browser.

Performance: How Much Does Session Replay Cost Your App?

Session replay performance impact depends on implementation, sampling, event volume, and the complexity of the application. A recording tool has to observe DOM mutations, serialize changes, listen for browser events, process payloads, and transmit data. On a busy single-page app, that's real CPU work, memory use, network traffic, and storage.

Always-on tools mitigate this with sampling, batching, compression, and asynchronous loading. Even so, the work happens during ordinary sessions — including the overwhelming majority in which nothing goes wrong. The more detailed the capture, the more important it is to measure the effect on real devices and slower connections.

On-demand replay changes the baseline. A dormant loader sits on the page at minimal cost and activates only when a diagnostic session is requested. Clairvio's loader is under 1 kB and does nothing until a session begins; the full recorder is only fetched at that point. For applications where continuous capture isn't necessary, that's a meaningfully smaller default footprint.

No approach is impact-free, and no vendor should claim otherwise. Test your configuration, understand what's collected, and verify performance across browsers and device classes. The practical question isn't whether replay has a cost — it's whether you pay that cost for every visitor or only for the sessions that need it.

Data Volume vs. Debugging Signal

Always-on replay produces a large historical dataset. That can be valuable, but volume doesn't automatically produce clarity. Engineers end up searching through recordings, correlating timestamps, filtering by route, and trying to determine whether a given replay is even the session the customer was complaining about.

On-demand capture produces fewer, more intentional sessions. Support associates a replay with a ticket. QA labels a reproduction with a build or test case. Engineering asks for a recording from a specific account, browser, or workflow. The resulting dataset is narrower and far easier to interpret.

It also has a direct effect on cost, since most replay pricing scales with sessions recorded — meaning always-on bills you in proportion to your traffic rather than in proportion to your bugs.

There is a real limitation here, and it's worth stating plainly: if a user reports an issue after it has disappeared, an on-demand tool cannot reconstruct a session that was never captured. Always-on recording has the advantage when unknown, intermittent issues require historical discovery. Most teams close that gap by pairing targeted replay with conventional telemetry — error tracking, traces, logs, and performance metrics — which is where intermittent issues surface first anyway.

Privacy, Security, and Retention

Session replay can expose sensitive information if it isn't configured correctly. Forms, account details, URLs, text nodes, and page content may all contain personal or confidential data. Any replay strategy needs masking or blocking rules, a clear retention policy, restricted access, and a review against applicable privacy law.

Always-on recording increases the amount of data you have to govern. Even with effective masking, more sessions mean more records to store, secure, audit, and eventually delete — and more surface area for a subject access request or a breach.

On-demand capture shrinks the default collection surface. You request a recording for a particular support case or reproduction, and collection stops when the investigation ends. That doesn't eliminate your privacy obligations, but it makes data minimisation substantially easier to implement and to explain to a reviewer.

Which Approach Is Better for Debugging?

Choose always-on session replay when:

• You need to investigate unknown issues after they've already happened.
• Product teams require broad visibility into user behavior.
• You have the budget and processes for storage, access control, and retention.
• Your application has been tested against the recording overhead and tolerates it.

Choose on-demand session replay when:

• Support or engineering can ask a user to reproduce the issue.
• You want detailed browser context without recording every visitor.
• Privacy and data minimisation are high priorities.
• You want a focused diagnostic workflow connected to tickets or QA cases.
• You want to keep the default performance footprint as small as possible.

The decision doesn't have to be absolute. Plenty of teams run always-on sampling across a narrow set of critical flows while using on-demand capture for support-led investigations and hard reproductions. The important thing is to match the collection model to the job: broad behavioral analysis and historical discovery need different tooling than targeted debugging. Our buyer's guide breaks down where each tool in the category lands on that spectrum.

A Practical Workflow for Targeted Debugging

A useful on-demand workflow starts with an existing signal — an error alert, a customer ticket, a failed test, a suspicious API response. That signal identifies the session or workflow worth investigating. The team then sends a magic link or the customer opens the embedded widget, the user or tester reproduces the issue, and the captured DOM session is reviewed alongside console errors, network requests, and navigation events.

That context answers questions a stack trace can't. Did the button actually become disabled? Was the request blocked, or did it return an unexpected response? Did a client-side exception interrupt navigation? Did the page render differently after a redirect? Once the issue is understood, capture stops and you retain only what your policy requires.

Try Focused Browser Diagnostics with Clairvio

Clairvio is built for engineering, QA, and support teams that need real browser context without making continuous recording the default. The dormant sub-1 kB loader stays out of the way until a session is requested, and either a magic link or the embedded support widget captures a live or recorded reproduction.

What comes back is the detail that makes web bugs actionable: a DOM replay of the session, console errors, network requests and responses, navigation events, an environment snapshot, and masked inputs. If you're evaluating on-demand session replay — or specifically looking for session replay without always recording — take a look at Clairvio and see how a focused diagnostic workflow fits into your application.