JavaScript (JS) errors directly affect the quality of front-end applications. Therefore, it is particularly important to locate and diagnose JS errors. The JS error diagnosis feature provided by browser monitoring of Application Real-Time Monitoring Service (ARMS) can quickly and accurately locate and diagnose JS errors.
Prerequisites
Background information
- Difficult to replicate
For example, when User A accesses a page, the page is loaded on the local browser of User A. Because the loading duration of the page is affected by factors such as the region, network, browser, or carrier, the actual situation occurred when User A accessed the page cannot be replicated.
- Lack of monitoring information for in-depth investigation
Most browser monitoring services use the PerformanceTiming object to obtain the full page loading time, which does not include loading information of static resources. As a result, the performance bottleneck cannot be located.
ARMS browser monitoring can use the source map to find the real location of the error in code and use the user behavior backtracking feature to replicate the JS error. This allows developers to quickly locate errors in source code and corresponding code blocks.
Step 1: Install the ARMS agent
To comprehensively monitor frontend applications, you must install the ARMS agent for your frontend applications. Select a method to install the ARMS agent as needed. For more information, see Access overview of browser monitoring.
Step 2: View the error overview
Step 3: Diagnose a specific error
- On the Frequent Errors tab, click Diagnose to access the diagnosis page.
- In the error chart, go to the Exception Insight dialog box at a specific time point and then access the diagnosis page.
Step 4: View error details
Onsite JS error information includes the first occurrence time, first occurrence version (optional), error name, error type, device, operating system, browser, and the page, file, row, and column where the error resides. As shown in Figure 1, the map module on the real-time dashboard reported an invalid data error during the update, and the error occurred in line 1 and column 79585.

Step 5: Locate the error code
The information acquired from the JS error details is insufficient for problem diagnosis, because online code is unreadable after being compiled, compressed, and obfuscated. Although you can see the error occurred in line 1 and column 79585, this is not the actual location in the source code. In this case, you must use the source map for source code mapping.
Step 6: View the backtracked user behaviors
The source code error occurred when invalid data was loaded during the creation of the map component. However, invalid data may appear in a variety of forms. Null judgment and fault tolerance have been performed for data in the preceding code, but the invalid data exception is still triggered. If a snapshot of the data at the time of the error can be taken, you can locate the problem more accurately. However, onsite data is usually unavailable in global exception capture, and troubleshooting depends on only the data information reported with the exception.
Is there any other way available to help troubleshooting? The best way is to replicate the problem. ARMS browser monitoring defines each event node on the page as user behavior, such as page loading, route jumps, page clicks, API requests, and console output. User behavior is connected in chronological order to form a behavior link. Behavior backtracking upon the error can help developers replicate the problem.
The user behavior backtracking upon the error shows that there is an API request before the error. This API request tries to request real-time update of the map module. However, the returned data is ConsoleNeedLogin, indicating logout from the page. This is the root cause of invalid data.