Finding which client script caused an error a user can't reproduce

[GPYU]

In a controlled test on an Australia PDI, I introduced a deliberate TypeError in an onLoad Client Script on the Incident form. The platform caught it and logged it at log level, not error. Live in the console, I could attribute it — the stack named the generated handler, and the rendered page had the mapping back to the script name and sys_id. After closing the tab, all I could find was the timing record in syslog_client_trans_det — type, duration, order, a shortened name. No exception message, no stack, no failure flag. Searching syslog for the exception text and probe name returned no matches. For people running real instances: when a form breaks for one user and you can't reproduce it, what native tools or retained evidence would you check next?

[hemalathahs2007]

I would first check the browser Developer Console and JavaScript Log for client-side errors. I’d also use Field Watcher to identify which client scripts or UI policies are affecting the form. Finally, I’d correlate the user, timestamp, form/record, and session details. Since this is a client-side exception, the full stack trace may only exist in the browser session and may not be retained in syslog after the tab is closed.

[GPYU]

Thanks, this is helpful. The point about the full stack trace potentially existing only in the browser session is particularly useful.

Our challenge is mainly with troubleshooting after the event. For example, if an end user encounters a client-side exception and reports it later, after the browser tab/session has already been closed, we would like to determine which Client Script, UI Policy, or other client-side customization caused the exception.

In that situation, is there any native ServiceNow mechanism that persistently captures the JavaScript exception/stack trace together with context such as the user, timestamp, table/form, record, and session?

Or would this require custom client-side instrumentation/logging to capture that information at the time the exception occurs?

We are specifically trying to understand what diagnostic information remains available after the original browser session has ended.

[cassie258elks]

I’d check syslog/application logs, transaction logs, browser/session logs, and any Script Error or client-side debugging records retained by the instance, then correlate them by user, timestamp, transaction, and script sys_id. If the exception is only surfaced through the browser console and syslog_client_trans_det retains timing metadata without the error payload, there may simply be no server-side native record of the client exception after the session ends. In that case, reproducing with client debugging enabled or capturing the affected user’s console/network/session evidence is usually the next practical step.

[GPYU]

Thanks. Could you name the exact native table, module, or setting behind “Script Error or client-side debugging records,” and whether it retains the actual exception message and stack after the affected user closes the tab?

Have you used it on a real instance to diagnose a non-reproducible client-side failure reported later? If so, which release/UI was involved, and did capture need to be enabled beforehand?

Our test found timing metadata in syslog_client_trans_det, but no exception payload. A concrete example would help distinguish retained diagnostics from tools that require reproducing the issue.