Session Recording for Developers: Debug Faster

Why Developers Need Session Recording

Every developer has received a bug report like this: “I clicked the button and nothing happened. I’m using Chrome. Please fix.” You check your staging environment. Everything works. You ask for more details. The user can’t remember what page they were on. The ticket sits in the backlog for two sprints because nobody can reproduce it.

This isn’t a process failure—it’s an information gap. The user experienced a real problem, but the signal got lost between their browser and your issue tracker. Traditional debugging tools (browser DevTools, logging, error monitoring) all require either being present when the bug occurs or guessing what happened from fragments of data.

Session recording bridges that gap. Instead of asking users to describe what happened, you watch what happened—every click, scroll, keystroke, and page transition—alongside the technical data your code produced during that session. Console output, network requests, JavaScript errors with full stack traces—all synchronized to a single timeline.

This is not a UX analytics tool repurposed for debugging. For developers, session recording is a production debugger—one that runs on every user’s machine, captures the data you need, and waits for you to query it when a bug report comes in.

Session Recording as a Debugging Tool

Reproduce Any Bug Without the “What Browser?” Dance

When a user reports a problem, the first thing most teams do is try to reproduce it. That means asking for browser version, operating system, screen size, the exact steps they took, and whether they had any browser extensions installed. Half the time, the user can’t answer those questions. The other half, the information they provide doesn’t lead to a reproduction.

With session recording, you skip that entire cycle. Every recorded session captures the browser, OS, screen dimensions, and viewport automatically. You see the user’s exact path through your application—every page they visited, every form they filled out, every button they clicked. If something went wrong, you see exactly when and where.

Console + Network Logs Synchronized to Replay

The visual replay alone is useful, but what makes session recording a genuine debugging tool is the data running alongside it. Inspectlet’s replay player includes two tabs that developers reach for constantly:

The Console tab shows JavaScript console output synchronized to the replay timeline. Every console.log, console.warn, and console.error your application produced during the session appears in order, timestamped to the exact moment in the replay. If your code logged a state change, an API response, or a debugging message, it’s there.

The Network tab logs XHR requests made during the session—method, URL, HTTP status code, timing, and response size. If an API call returned a 500 or took 8 seconds to respond, you see it right next to the moment the user’s interface froze. The tracking script captures these by monitoring XMLHttpRequest calls, so all AJAX requests are logged automatically.

Together, these tabs give you DevTools-level insight into a session that happened hours or days ago, on a machine you’ll never touch.

Error Logging with Stack Traces

Inspectlet automatically hooks into window.onerror to capture JavaScript errors as they happen. Each error record includes the error message, source file, line number, column number, and the full stack trace. Errors are deduplicated with a cooldown period to avoid flooding—if the same error fires repeatedly, it’s grouped rather than logged dozens of times.

The error logging dashboard shows each unique error with its occurrence count and a sparkline of frequency over time. But here’s what makes it different from standalone error monitoring: click any error and you jump directly to a session recording where it occurred, at the exact moment it fired. You don’t just see a stack trace—you see the user action that triggered it, the page state before and after, and whether the user recovered or abandoned.

Setting Up for a Development Workflow

Installation

The base installation is a script tag, the same as any analytics tool. Add it to your page template or inject it via a tag manager:

<script type="text/javascript">
(function() {
    window.__insp = window.__insp || [];
    __insp.push(['wid', YOUR_SITE_ID]);
    var ldinsp = function(){
        if(typeof window.__inspld != "undefined") return;
        window.__inspld = 1;
        var insp = document.createElement('script');
        insp.type = 'text/javascript';
        insp.async = true;
        insp.id = "inspsync";
        insp.src = ('https:' == document.location.protocol ? 'https' : 'http')
            + '://cdn.inspectlet.com/inspectlet.js?wid='
            + YOUR_SITE_ID + '&r=' + Math.floor(new Date().getTime()/3600000);
        var x = document.getElementsByTagName('script')[0];
        x.parentNode.insertBefore(insp, x);
    };
    setTimeout(ldinsp, 0);
})();
</script>

Replace YOUR_SITE_ID with your numeric site ID from the Inspectlet dashboard. The script loads asynchronously and won’t block your page rendering.

Tagging with Build and Deploy Info

This is where session recording becomes a real part of your development workflow. Use tagSession to attach metadata to every session:

__insp.push(['tagSession', {
    build: '2.4.1',
    env: 'production',
    feature_flags: 'new_checkout,redesigned_nav',
    deploy_id: 'deploy-20260404-1423'
}]);

Now you can filter sessions by build version, environment, feature flag cohort, or deploy. When a bug report comes in after a release, search for sessions tagged with that specific build to see if the issue is new. When a feature flag experiment causes problems, filter by that flag to isolate affected sessions.

User Identification

Link sessions to user accounts so you can find any specific user’s session when they submit a support ticket:

__insp.push(['identify', currentUser.id]);

Once identified, you can search for that user’s sessions in the dashboard using Magic Search. A support ticket that says “user #4821 can’t save their profile” becomes immediately actionable: search for user 4821, find the session, watch what happened.

Environment-Aware Configuration

Most teams don’t want to record every environment. Use conditional loading to control where recording runs:

if (window.APP_ENV === 'production' || window.APP_ENV === 'staging') {
    __insp.push(['wid', YOUR_SITE_ID]);
    __insp.push(['tagSession', {env: window.APP_ENV}]);
}

Some teams record staging for internal QA and production for real user sessions. Use separate Inspectlet site IDs for each environment to keep the data separate, or use the same ID with an env tag to filter in the dashboard.

Debugging Workflows

Customer Bug Report → Session → Root Cause

Here’s the workflow that saves the most developer time:

1. A customer reports a bug through your support channel
2. Use Magic Search to find their session—search by user ID, URL visited, browser, or time window
3. Watch the replay to see exactly what happened from the user’s perspective
4. Switch to the Console tab to see any JavaScript errors or log output at the moment of failure
5. Switch to the Network tab to check if an API call failed or timed out
6. You now have the reproduction steps, the browser context, and the technical root cause—without a single back-and-forth with the user

What used to take a day of email exchanges now takes five minutes.

Error Logging Dashboard → Triage → Fix

Instead of reacting to bug reports, use the error logging dashboard proactively. Check it after every deploy:

1. Open the error logging dashboard and sort by occurrence count
2. Look for new errors that appeared after your latest deploy (the sparkline shows timing)
3. Click an error to jump to a session where it occurred
4. Watch the replay to understand the user impact—is this a cosmetic console error or does it break functionality?
5. Use the stack trace to identify the exact file and line that needs fixing

Performance Investigation

When users report that your app feels slow, the Network tab in session replay becomes your primary investigation tool. Look for:

• Slow API calls: XHR requests with response times over 2–3 seconds. The Network tab shows timing for each request, so you can identify which endpoints are the bottleneck.
• Failed requests: 4xx and 5xx status codes on API calls that should succeed. Correlate these with what the user saw—did the UI show an error message or did it fail silently?
• Cascading requests: Patterns where one slow request blocks a chain of dependent requests. You’ll see these as clusters of requests that all fire after a long gap.

SPA Navigation Issues

Single-page applications introduce a class of bugs that traditional page-level logging misses. Inspectlet automatically tracks virtual page views by hooking into the History API, so session replays show the full navigation flow through your SPA—including route changes that don’t trigger full page reloads.

This is especially useful for debugging issues where:

• A route change fires but the component doesn’t render correctly
• State from a previous page leaks into the next view
• Back button behavior doesn’t match user expectations
• Deep links don’t load the correct state

Advanced Developer Configuration

Custom Routing with disableVirtualPage and pageUrl

Inspectlet’s automatic virtual page tracking works well for most SPAs, but some applications need more control. If your app changes the URL for reasons that aren’t navigations (e.g., updating query params for filter state), disable automatic tracking and fire page views manually:

__insp.push(['disableVirtualPage']);

// Fire manually when a real navigation occurs
function onRouteChange(newPath) {
    __insp.push(['virtualPage']);
}

For applications that use hash-based routing or have URLs you want to normalize, use pageUrl to override what Inspectlet records:

__insp.push(['pageUrl', '/app/dashboard']);

This keeps your session data clean and makes filtering by URL in Magic Search more predictable.

Cross-Domain Tracking

If your application spans multiple domains (e.g., app.example.com and checkout.example.com), enable cross-domain tracking to keep the session continuous:

__insp.push(['crossDomain']);

Without this, the user would appear as two separate sessions—one for each domain. With it, you see the complete flow across your entire application.

Iframe Content Recording

If your application embeds content in iframes (payment forms, third-party widgets, embedded editors), you can include that content in the recording:

__insp.push(['linkiframes']);

To exclude specific iframes (e.g., a third-party payment iframe where you don’t control the content or want to avoid capturing sensitive data), add the exclusion class to the iframe element:

<iframe class="inspectlet-disable-iframe-inject" src="..."></iframe>

Subdirectory Deployments

If your application is deployed under a subdirectory rather than the root domain, specify the cookie path to ensure tracking cookies are scoped correctly:

__insp.push(['cookieLocation', '/app']);

API Access for Automation

Inspectlet provides a REST API at api.inspectlet.com for programmatic access to session data. Authenticate with HTTP Basic using your account email and API key:

curl -u "you@example.com:YOUR_API_KEY" \
    "https://api.inspectlet.com/v1/websites/SITE_ID/sessions"

Use the API to build integrations: pull session counts into your CI dashboard, create links to relevant sessions from your error tracking tool, or automate weekly reports on error-heavy sessions. The API supports listing sessions and retrieving individual session details.

Sharing and Collaboration

Shareable Replay Links

When you find a session that demonstrates a bug, you need to share it with your team. Inspectlet generates shareable replay URLs that include an access key—anyone with the link can watch the replay without needing an Inspectlet login. Paste the link directly into a GitHub issue, Slack thread, or Jira ticket.

This changes the dynamic of bug discussions. Instead of describing what happened in a paragraph, you share a 30-second video of the actual user experience. The entire team sees the same thing.

Downloading Sessions for Offline Review

For situations where you need to archive a session or share it outside your organization, Inspectlet supports downloading sessions as self-contained HTML files that replay offline. This is useful for post-mortems, compliance documentation, or sharing with external partners who don’t have dashboard access.

Team Access

Grant dashboard access to your development team, QA team, and support team. When support identifies a user issue, they can pull up the session themselves and either resolve it or pass the replay link to engineering with full context. This eliminates the “can you reproduce this?” bottleneck.

Privacy-Conscious Recording in Development

Recording user sessions means handling user data responsibly. Inspectlet provides granular controls so you capture the debugging data you need without recording anything you shouldn’t.

Sensitive Data Masking

Password fields are automatically excluded from recordings—no configuration needed. For other sensitive fields (credit card numbers, SSNs, personal identifiers), add the inspectlet-sensitive class to mask the input content:

<input type="text" name="ssn" class="inspectlet-sensitive" />

For stricter control, use the inspectletIgnore class to exclude an entire element and all its children from recording. Or flip the model entirely with inspectlet-whitelist—only elements with this class will have their text content recorded.

For a complete guide to privacy controls and compliance frameworks, see our visitor recording privacy guide.

XHR Payload Control

The Network tab captures XHR requests by default, which is essential for debugging. If your API responses contain sensitive data you don’t want recorded, you can control this through the dashboard’s XHR recording toggle. This lets you keep the debugging benefits of seeing request methods, URLs, status codes, and timing while excluding response payloads.

Environment Filtering

Use conditional script loading to ensure you only record in environments where you have user consent. Most teams record production (with consent) and staging (internal only), and skip development and test environments entirely. Tag sessions with the environment name so you can always tell which is which.

Integrating with Your Dev Workflow

CI/CD Tagging

Inject build metadata into your Inspectlet configuration as part of your deployment pipeline. Most build tools expose environment variables you can template into your script tag:

__insp.push(['tagSession', {
    build: process.env.BUILD_VERSION,
    commit: process.env.GIT_SHA.substring(0, 7),
    deploy_time: new Date().toISOString()
}]);

After a deploy, filter sessions by the new build version. If error rates spike, you know exactly which deploy caused it and can watch affected sessions to understand the impact.

Error Alerts and Triage

Build a post-deploy checklist that includes checking the error logging dashboard for new errors. Combine this with session tagging: if new errors appear only on sessions tagged with the latest build, you have a clear regression. Click through to the session, watch the replay, and decide whether to roll back or hotfix.

QA Integration

Give your QA team access to session recordings. When they find a bug during testing, they can share the replay link instead of writing reproduction steps. This is faster and eliminates the “works on my machine” problem—the recording shows exactly what happened on their machine.

Session Recording vs. Traditional Debugging Tools

Session recording doesn’t replace your existing debugging tools—it fills the gaps between them.

Browser DevTools are the gold standard for debugging when you can reproduce the issue locally. But they only work when you’re present. Session recording captures the equivalent data (console, network, errors) for every user session, whether you’re watching or not.

Error monitoring tools (Sentry, Bugsnag, etc.) capture errors and stack traces, but lack the user context. You see what broke but not why the user triggered it or what they experienced as a result. Session recording adds the visual and behavioral layer—click the error, watch the session.

Application logging captures server-side events but misses everything that happens in the browser. Session recording captures the client side: what the user clicked, what JavaScript executed, what the UI actually rendered.

Analytics tools tell you what happened in aggregate (10% of users dropped off at step 3) but not why. Session recording lets you watch individual sessions to understand the cause behind the metric.

The most effective debugging setup uses all of these together. Session recording becomes the glue that connects an error alert to a stack trace to a user experience to a root cause.

Frequently Asked Questions

Does the recording script affect my application’s performance?

The script loads asynchronously and is designed to have minimal impact on page load time and runtime performance. It runs outside your application’s critical path. The tracking code uses passive event listeners and batches data transmission to avoid interfering with your application’s responsiveness.

Can I search for a specific user’s session?

Yes. If you’ve called __insp.push(['identify', userId]), you can search for that user in Magic Search. You can also search by URL visited, browser, device, operating system, session tags, or time range. Multiple filters combine to help you find the exact session you need.

How does the Console tab capture logs?

The tracking script intercepts console methods (console.log, console.warn, console.error) to capture output alongside the session timeline. Logs appear synchronized with the visual replay, so you see exactly what your code logged at each moment during the session.

Does session recording work with single-page applications?

Yes. Inspectlet automatically detects route changes by hooking into the History API, and records them as virtual page views. The replay shows the full navigation flow, including route transitions that don’t trigger full page reloads. For custom routing needs, use disableVirtualPage and fire page views manually.

Can I use the API to integrate session data into my tools?

Yes. The REST API at api.inspectlet.com supports listing sessions and retrieving session details. Authenticate with HTTP Basic using your account email and API key. Use it to pull session links into your issue tracker, build dashboards, or automate post-deploy monitoring.

How do I avoid recording sensitive user data?

Password fields are excluded automatically. Use inspectlet-sensitive on inputs to mask their values, inspectletIgnore to exclude entire page sections, or enable the global “censor all inputs” toggle. XHR payload logging can be controlled from the dashboard. For full details, see the privacy guide.

What’s the difference between the error logging dashboard and a dedicated error monitoring tool?

Dedicated error monitoring tools like Sentry give you deeper error aggregation, alerting rules, and release tracking. Inspectlet’s error logging dashboard is focused on the connection between errors and user experience—every error links directly to the session where it occurred. Many teams use both: Sentry for alerting and aggregation, Inspectlet for understanding the user impact and reproduction steps.