Having trouble with recordings? Below are some tips for getting past some common issues
The most common solution is...
Update posthog-js
We're always making improvements to the recordings feature, so you'll want to make sure that you're running the latest version of posthog-js on your website.
To check the version that you're using, you can run the following in your browser console:
Recordings are not being captured
There are a few common reasons that you may not see recordings appear in your project.
1. Authorized domains for recordings
In your project settings page, there's a section for 'Authorized URLs'. This is the list of domains where posthog will capture recordings. You should make sure it's not too restrictive.
For example, you may have https://www.example.com in the list. This will stop PostHog from capturing recordings on https://example.com.
If no domains are set here, PostHog will capture recordings on all domains.
2. posthog-js configurations
If you had previously disabled session recordings, you may have set the disable_session_recording option to true in posthog-js.
To re-enable session recordings you want to either remove the disable_session_recording option or set it to false.
You can read more about posthog-js configurations here.
3. Content security policy
When recordings are enabled, postHog-js will fetch a recorder.js script from the PostHog server. (This is not included in the default posthog-js to minimize the default bundle size)
Depending on your content security policy, this script may be blocked. If you have a default-src, script-src, script-src-elem, or connect-src directive in your CSP, you may need to ensure that PostHog doamins are permitted (see CSP documentation).
If PostHog is being blocked by your content security policy, you should see an error message in your developer console with more details.
4. Ad/tracking blockers
Some ad/tracking blockers will block PostHog from fetching posthog-js. If you're testing your app locally, you may need to disable any ad/tracking blockers that you're running in your browser.
Deploying a reverse proxy is the best way to avoid tracking blockers intercepting calls to PostHog.
Replay of recording looks incorrect or buggy
If you're having issues with recordings not looking correct, there are a few things you can:
Message too large warning
When we capture data from your page we compress it and allow very large messages to be sent to our servers for storage. But even then sometimes we receive data from your page that is too large to be ingested.
This almost always means that playback won't be accurate. For example: you might notice missing styles or page navigation not being reflected in the playback.
The only way to fix this is to reduce the amount of data that you send to our service. Learn how to restrict what you capture in our privacy docs
Ensure your website permits PostHog CORS
Most assets rendered on your website or app are captured inline – meaning we keep a copy of the icon, css etc. to use when replaying. For some assets however, this is either too difficult or too costly to do, so instead we load them directly from the original webserver (just like your website does). This can lead to CORS issues where the webserver does not permit us.posthog.com (or eu.posthog.com) to load the required asset. Unfortunately we cannot easily detect when this happens, but the browsers's developer tools (Option + ⌘ + J, or Shift + CTRL + J) will log when these errors occur saying something like:
If you see errors like this, please add app.posthog.com to the list of permitted domains in your webservers CORS configuration.
Adjust the crossorigin attribute on stylesheets
If the crossorigin attribute is not set on link elements a Chrome specific protection will prevent programmatic access to stylesheet rules (e.g. stylesheet.cssRules throws an exception). This means that styles on your site render as expected but they cannot be captured by PostHog in order to recreate the session during playback.
Setting crossorigin="anonymous" is the safest value you can set for the parameter as no user credentials are added to the request.
Ensure assets are imported from the base URL in Svelte
By default, base and assets imported from $app/paths in Svelte use relative asset paths during server-side rendering.
For apps with SSR enabled you should set relative to false in the paths object of your config. This ensures all asset URLs will correctly be resolved against the base URL rather than the current page.
Filtering can't find my custom events
The most common reason for this is that you're trying to filter by events that weren't sent by the web SDK. For example, from another tool like Segment or one of our backend SDKs.
Session replay relies on the $session_id property added to events by the web SDK to link events to sessions.
To workaround this, you can use the posthog.onSessionId method in the web SDK to register a callback that will be called each time the session ID changes. You can send this to your backend and add the $session_id property to your backend events.
Browser freezes or crashes when recordings are enabled
Some Cookie banners or "CMP"s modify the webpage in reaction to any changes to cookies, which can cause an infinite loop. If you are using a tool like this and experience the webpage becoming unresponsive or slow then try configuring posthog to use persistence: "localStorage+cookie". This will use localStorage for the majority of storage needs, bypassing the infinite loop issue sometimes caused by cookie management tools.
Network payload capture is not capturing headers
Browser do not automatically allow JS to read headers from cross-origin requests. So, when making a request from app.mywebsite.example to api.mywebsite.example headers are not available to be copied and reported.
You need to add Access-Control-Expose-Headers: * as a header on responses from api.mywebsite.example to allow all headers to be read cross origin. You can specify which headers you want to be available Access-Control-Expose-Headers: Content-Encoding, X-Correlation-Id if you don't want all headers to be accessible.
Recorder Limitations
Due to the complexity of browser rendering and replay, some web resources are unable to be recordered or playedback. These include:
- Object elements - Most object elements cannot be played back. Non-HTML native plugins such as Flash or Silverlight cannot be recorded
- Heavy animations - Some heavier animations such as SVG or Lottie animations may be throttled or ignored entirely due to the performance overhead in recording and replaying
- Iframes - iframes from the origins under your control can be recorded and played back. See iframe recording for more info.
Angular performance
It is sometimes necessary to run session replay outside of the Angular zone. See the PostHog Angular docs for more detail
Report your specific issue
To report a specific problem, you can open a GitHub issue. To help us figure it out as quickly as possible, please include the following information:
- The URL of the page that you're trying to record
- The version of posthog that you're using
- The version of posthog-js that you're using
- Details about the specific issue with your recording (e.g. how it looks and how it should look)
- If you're on posthog-cloud, a link to the specific recording
- Any unique details about your website (e.g. the frameworks that you're using etc.)