If replay is not working as expected, try these troubleshooting tips to get it up and running again!
Replay not loading
This issue can be caused by one of the following:
- Data from the Web SDK is not captured properly. In that case, the replay server triggers an error which that is hidden from regular users.
Sometimes, replay is unable to render a screen. For example, a user's interaction with a screen happens too fast for Tealeaf to capture the corresponding DOM/HTML, so the screen is not rendered in the interface. A missing screen doesn't prevent you from replaying screens from the remainder of the session. If the missing screen was the result of the capture mechanism not keeping pace with the user's actions, the same screen might be available for replay from a different session.
- The static content is not rendering.
Check if this is an internal application or publicly available app and if there are errors in the browser console or network tab. If this is the case, use the proxy replay rule. For more information, see the "Replay Rules configuration file" article.
- The replay button was used, which renders the replay in a video mode. If the session is too big, some of the pages may be skipped or get stuck.
Replay loading slowly
You might notice that it takes longer than usual for a session to load from the search results page. Or, when you select a page from the Replay navigation, you might notice that it takes longer than normal for the page to render in the view area.
When replay is slower than normal, select the Loading details icon (in the Auto Replay scrubber bar) for the page you are viewing and take note the performance metrics.
When you open a ticket about the slow replay, include the information from the Loading details window. Information from the Loading details window can help Acoustic support and services personnel troubleshoot a slow replay.
Note: The information presented in the Loading details window can vary slightly for sessions replayed with the Session Upload feature, all potential fields are defined here.
- Session load details
- The total load time for a session consists of the following parts:
- Load from search
The time in seconds it took to load the session initially to Replay from the session search results page.
- Load from cache
The time in seconds it took to load the session from cache.
The Replay server caches session data. Access to this metric can help the support team debug slow replays.
- Build page list
The time in seconds it took to build the list of session pages in the navigation page.
- Load from search
- Load details for the selected step
- The total load time for a step consists of the following parts:
- Load content
The time in seconds it took to load content for the selected step.
- Apply updates
The time in seconds it took to apply updates for the selected step.
During replay, the Replay server performs a series of updates on the DOM, such as making the links not clickable or modifying asset URLs. The Apply updates value refers to the time that is associated with those types of updates.
- Apply rules
The time in seconds it took to apply replay rules for the selected step.
- Load page from cache
The time in seconds it took to load the selected page from the cache.
When you click a step or page, what you see in the view area is the DOM / HTML. The page is cached by the Replay server. The Load page from cache value refers to the time that is associated with the caching process.
- Load content
Security preventing retrieval of image and CSS files
Akamai CDN security or other internal security can occasionally blacklist Tealeaf IP addresses.
As a result, Tealeaf is prohibited from retrieving image and CSS files from your website, which can negatively impact Session Replay, Content Retrieval Service downloads, and Session Export.
To ensure Session Replay, Content Retrieval Service (for beta customers only) and Session Export continue to work as intended, you can whitelist the following IP addresses:| Dallas Data Center | Frankfort Data Center | Washington DC Data Center | Sydney Data Center |
|---|---|---|---|
|
**** Updated IP addresses:
Discarded IP addresses: 169.45.165.27 169.45.165.28 169.45.165.30 169.45.179.8 169.45.179.9 3.92.170.190 34.235.222.2 52.71.90.231 |
***Current IP addresses
Discarded IP addresses: 159.122.66.55 159.122.66.56 159.122.66.57 3.127.26.198 52.58.223.4 18.194.109.83 |
** Updated IP addresses:
Discarded IP addresses: 169.55.100.132 169.55.100.135 169.55.100.139 169.55.109.72 169.55.109.73 |
++ Updated IP addresses
Discarded IP addresses: 13.236.46.193 13.239.143.6 52.62.229.129 168.1.3.86 168.1.3.87 168.1.3.93
|
+++ Date to be determined (TBD), the Frankfort data center IP addresses will be changing to support a network improvement that was rolled out after the migration from IBM to Acoustic.
++ On July 31st 2020, the Sydney data center IP addresses will be changing to support a network improvement that was rolled out after the migration from IBM to Acoustic.
** The Tealeaf migration from IBM to Acoustic is being rolled out in phases. The Washington data center IP addresses will change on April 18th, 2020. Update the data center IP addresses accordingly.
*** The Tealeaf migration from IBM to Acoustic is being rolled out in phases. The Frankfort data center IP addresses changed on September 11, 2020. Update the data center IP addresses accordingly.
**** The Tealeaf migration from IBM to Acoustic is being rolled out in phases. Update the data center IP addresses accordingly.
As a Tealeaf customer, you need to whitelist the IP addresses in all your network security tools (internal or external). For example, if your site is using Akamai CDN, you need to whitelist the Tealeaf IP addresses in your Luna dashboard.