Logging and Debugging
Server-Side Logging (gs)
These methods belong to the GlideSystem (gs) object and are used in server side scripting such as Business Rules, Script Includes.
1. gs.info(), gs.warn(), gs.error()
These are the modern standards. They write to the System Log [sys_log] table. They are “level-aware,” meaning you can filter your logs by severity.
- Example: gs.info(“User {0} has logged in.”, gs.getUserName());
- Best for: Production-ready code and general auditing.
- Use gs.info() if you are building a Scoped Application or want to follow the latest ServiceNow best practices.
2. gs.log()
The “old reliable.” It also writes to the System Log but allows you to specify a Source column, which makes filtering much easier in the list view.
- Example: gs.log(“Processing record”, “MyCustomApp”);
- Use gs.log() only if you are working in the Global Scope and specifically want to use a custom string in the Source column for easy filtering.
- Note: This is not available in Scoped Applications (you must use gs.info there).
3. gs.print()
It writes to the localhost log file on the server but does not always appear in the sys_log table UI.
- Example: gs.print(“Hello from the background script”);
- Best for: Running scripts in the “Background Scripts” module where you want an immediate output on the screen.
4. gs.debug()
This only logs if the system property glide.debug.log (or a specific session debug) is enabled.
- Example: gs.debug(“Variable X is: ” + x);
- Best for: Troubleshooting complex logic without cluttering the logs for every user.
Client-Side Logging (console)
These run in the user’s browser (Chrome, Firefox, etc.) and are used in Client Scripts and UI Scripts.
console.log() / console.debug()
These don’t write to the ServiceNow database at all. They write to the Browser Console .
console.log()
This is the standard way to output general information to the browser console. It is the most commonly used tool for “sanity checking” values while building a UI feature.
For example, print the new value while running OnChange Client script,
console.log(“The new value of the field is: ” + newValue);
console.debug()
Functionally, this is almost identical to console.log(). However, it is intended for “verbose” or “debug” level messages that you might not want to see all the time.
- Example: console.debug(“Current Field Value: ” + g_form.getValue(‘short_description’));
- Best for: Real-time debugging of UI behavior.
Note: Always remove these before moving code to Production, as they are visible to any tech-savvy user.
log.print()
In standard ServiceNow JavaScript, log.print is not a native global function. You might see this in specific integrations (like IntegrationHub ETL) or if a developer has created a custom log object. Usually, if you try to run this in a standard Business Rule, it will throw an error.
Method | Environment | Log Destination | Scoped App Compatible? |
gs.info() | Server | System Log (sys_log) | Yes |
gs.log() | Server | System Log (sys_log) | No (Global only) |
gs.print() | Server | Localhost File / Script Output | Yes |
gs.debug() | Server | System Log (if debug enabled) | Yes |
console.debug() | Client | Browser Console | Yes |
Server-Side Debugging
This applies to Business Rules, Script Includes, Scheduled Jobs, and UI Actions (server-side).
The Script Debugger
The Script Debugger is a built-in interface that allows you to set breakpoints. When the code hits that line, the system pauses execution, allowing you to inspect variable values in real-time.
- How to use: Open “Script Debugger” in the Filter Navigator, set a breakpoint (click the line number in your script), and trigger the action.
- Best for: Complex logic where you need to see how variables change step-by-step.
Script Tracer
The Script Tracer records every server-side script that executes during a transaction. It captures:
- Business Rules
- Script Includes
- Script Actions
- UI Actions (Server-side)
It shows you the order of execution and the state of the record before and after each script ran.
- Open the Tracer: Navigate to System Diagnostics > Script Tracer.
- Start Tracing: Click the Start Tracer button in the top right.
- Perform the Action: Go to your form (e.g., an Incident) and perform the action you want to debug (e.g., click “Update” or change the “State”).
- Stop and Analyze: Go back to the Script Tracer tab and click Stop Tracer.
- Review the Trace: You will see a list of every script that ran.
Session Debugging
ServiceNow allows you to toggle specific debug logs that appear at the bottom of your UI page.
- How to use: Navigate to System Diagnostics > Session Debug. You can choose “Debug Business Rule,” “Debug Security (ACL),” or “Debug SQL.”
- Best for: Seeing which Business Rules are firing and in what order.
Background Scripts
The Scripts – Background module is the “scratchpad” of ServiceNow. You can paste a snippet of code and run it immediately to see the output.
- Best for: Testing a specific function or a GlideRecord query without having to trigger a record update.
Client-Side Debugging
This applies to Client Scripts, UI Policies, and Catalog Client Scripts.
Since client scripts run in the browser,
- Console: Use console.log() to print values or debugger; in your code to force the browser to pause execution.
- Sources Tab: You can find your client script in the “Sources” tab and add breakpoints directly in the browser.
The JavaScript Log & Field Watcher
ServiceNow provides a built-in “JavaScript Log” window that sits inside the platform UI.
- Field Watcher: Right-click any field label and select Watch field. A pane opens at the bottom showing every script, policy, or ACL that touches that specific field.
- Best for: Figuring out “What script just hid this field?” or “Why did this value change to 10?”
Tool | Environment | Use Case |
Script Debugger | Server | Pausing execution and inspecting variables. |
Background Scripts | Server | Testing standalone code snippets quickly. |
Session Debug | Server | Watching Business Rules and ACLs in real-time. |
Field Watcher | Client | Tracking why a specific field’s value/visibility changed. |
Browser Console | Client | Inspecting UI errors and logging manual triggers. |