Session Recording Issues
Common issues in session recordings
Sessions are not appearing
Due to Content Security Policy
-
After adding the script to your app, visit a page with LogRocket running and open your browser's developer tools. (make sure that you are connected to the internet, too)
-
Check for any error messages mentioning LogRocket, like this:
This can be fixed by adding the following to your site's content security policy:
Content-Security-Policy: child-src 'self' blob:; worker-src 'self' blob:; script-src 'self' https://cdn.logrocket.io https://cdn.lr-ingest.io https://cdn.lr-in.com https://cdn.lr-in-prod.com https://cdn.lr-ingest.com https://cdn.ingest-lr.com https://cdn.lr-intake.com https://cdn.intake-lr.com; connect-src https://*.logrocket.io https://*.lr-ingest.io https://*.logrocket.com https://*.lr-in.com https://*.lr-in-prod.com https://*.lr-ingest.com https://*.ingest-lr.com https://*.lr-intake.com https://*.intake-lr.com https://*.logr-ingest.com https://*.lrkt-in.com
Note that the worker-src CSP directive isn't supported in Safari or mobile Safari and shouldn't be used in those browsers. Using it anyway might prevent LogRocket from running and may prevent you from recording sessions in those browsers.
Due to blocked Javascript
The LogRocket recording script (SDK) might be blocked by a browser extension or network security policy. Open your browser's dev tools to check if the requests are failing. If they are, be sure to add an exception for the domain the SDK is loaded from.
Due to LogRocket.init() call being placed incorrectly
Ensure that LogRocket.init()
is called before other code is loaded in your application:
// DOES NOT WORK!
import LogRocket from 'logrocket';
LogRocket.init('foo/bar')
import './myOtherModule';
Instead, make sure to import a separate file which contains LogRocket:
// in entry file
import './logrocketSetup';
import './myOtherModule';
// in logrocketSetup.js
import LogRocket from 'logrocket';
LogRocket.init('foo/bar');
Due to recording in an unsupported browser
If you are recording a session in an unsupported browser, the SDK will throw an exception which will be visible in the browser console. See this page for a list of supported browsers.
Sessions ending prematurely
Like the above problem, this can be caused by a number of things:
Not putting LogRocket on every page
If your app is not a single-page application (SPA), the LogRocket.init()
call must be put on every page. You can tell this is the cause if you have multiple sessions ending when a user navigates to the same page without init() called.
Sending too much data too quickly
Although extremely rare, this has been known to happen because of bugs which result in too many state changes that are queued to be sent to LogRocket. When this happens, LogRocket will stop recording to save on user bandwidth and print a warning to the console.
This can also happen if there are too many DOM changes. Browsers are pretty good at handling these, but LogRocket will shut down if too many happen within a reasonable period of time. Besides ruling out bugs in your app, also be sure you're not adding and mutating
HTML <base>
element missing an href
attribute
<base>
element missing an href
attributeThe HTML <base>
element specifies the base URL to use for all relative URLs in a document. If your HTML includes a <base>
element with no href
attribute, your sessions may not play correctly. To fix, add the missing href
attribute and record new sessions.
Sessions are broken up across subdomains
If you're seeing multiple sessions created as users traverse different subdomains on your site and you'd prefer to keep these contained to a single session, pass the rootHostname
option when calling LogRocket.init().
Styles are not appearing in recordings
LogRocket can sometimes take a few minutes to fetch the CSS from your website. If you're still not seeing the styles after ~10 minutes, then make sure the following are true:
- You are running on a publicly-available domain: Testing on localhost/VPN.
- You are not using
sourceMap
as an option in your Webpackcss-loader
config. - Your CDN keeps old versions of your assets publicly available. For example, if you have a CSS file named
main-[hash].css
, LogRocket's backend needs to be able to fetch this file to add it to the video. Alternatively, to make things simpler you could put the hash in the query part of the filename (e.g.,style.css?[hash]
). This should be easy to achieve using your CDN or storage provider and may already be enabled. - There are not
<style>selector { display: none }</style>
overridden by stylesheets later in<head>
. LogRocket moves all<link>
tags to the top of the<head>
. Use{ display: foo !important }
in the overriding style tag to fix this. - There are no
<style>
elements with more than 10,000 bytes of content.
Network requests are missing or not being recorded
This is often caused by other libraries interfering with LogRocket's network capture functionality.
isomorphic-fetch
Some libraries like isomorphic-fetch
will not work if you use the exported fetch:
// DO NOT DO THIS:
import fetch from 'isomorphic-fetch';
fetch(...);
// DO THIS:
import 'isomorphic-fetch';
fetch(...);
whatwg-fetch
In addition, make sure that you're not setting whatwg-fetch
to the window global before importing LogRocket:
// DO NOT DO THIS
new webpack.ProvidePlugin({
fetch: 'exports-loader?self.fetch!whatwg-fetch'
})
Instead, just import whatwg-fetch
normally into your bundle:
// DO THIS
import 'whatwg-fetch';
import LogRocket from 'logrocket';
LogRocket
is a singleton, so you can load it from any place in your application after this point.
apollo-client
If network requests are not appearing when using apollo client, add this code to your application:
import { ApolloClient } from 'apollo-client';
import { InMemoryCache } from 'apollo-cache-inmemory';
import { createHttpLink } from 'apollo-link-http';
const fetcher = (...args) => {
return window.fetch(...args);
};
const client = new ApolloClient({
link: createHttpLink({
uri: 'https://yourgraphql.api',
fetch: fetcher,
}),
cache: new InMemoryCache()
});
Other network libraries
LogRocket should be imported and initialized before libraries that wrap fetch or XMLHttpRequest (e.g., apollo-link, axios, xhr). Libraries like these often save a reference to fetch or XHR internally. When LogRocket sets up network capture by instrumenting fetch and XHR during initialization, these libraries may not use the newly-instrumented version. As a result, requests made with these libraries may not be visible to LogRocket. Your app's requests should be consistently captured if you're able to call LogRocket.init() before any network library code is loaded.
Memory Usage data missing
Not all browsers support the Performance.memory
API. If you see Memory Usage data missing from a session, this is likely the reason. CPU Usage data should still be present.
Capturing WebSocket errors
LogRocket doesn't record WebSockets by default. However, you can use WebSocket event listeners to send WebSocket data to LogRocket. For example, to capture WebSocket errors:
webSocketObject.addEventListener('error', evt => LogRocket.log(evt.data));
Fonts appear different on mobile or have ☒ in place of icons
Unexpected font rendering, or the presence of placeholder characters such as ☒, can sometimes occur if an app uses custom fonts. We recommend uploading your custom fonts (iOS, Android) to have the highest fidelity in session replay.
Updated about 2 months ago