Platform Debugging and Troubleshooting

Introduction

Debugging in ServiceNow spans multiple layers: client-side JavaScript in the browser, server-side Rhino scripts, database queries, and external integrations. Each layer has its own tools. A developer who knows how to systematically diagnose issues across all layers resolves problems in minutes that confuse others for hours.

---

Client-Side Debugging

Browser Developer Tools

For Client Scripts (which run in the browser), the browser's developer console is your primary tool:

// Add to Client Scripts for debugging:
console.log('onChange fired. newValue:', newValue);
console.log('g_form values:', {
    priority: g_form.getValue('priority'),
    state: g_form.getValue('state'),
    assigned_to: g_form.getValue('assigned_to')
});

Open DevTools (F12), navigate to Console tab, and watch for output as you interact with the form.

JavaScript Log / Debug Mode

User Settings (gear icon) → Developer → JavaScript Log

Enables verbose logging of all ServiceNow client-side events in the browser console.

---

Server-Side Debugging

Session Debug: Business Rules

Activate real-time Business Rule logging:

System Diagnostics → Session Debug → Business Rules → ON

Now navigate to a record and perform an action. The browser console will show each Business Rule that fired, its condition result, and output.

Session Debug: Security

System Diagnostics → Session Debug → Security → ON

Shows ACL evaluation details — which ACLs matched, which passed, which denied. Essential for diagnosing unexpected permission issues.

Session Debug: Database Queries

System Diagnostics → Session Debug → SQL → ON

Logs every SQL query executed in your session. Use to find N+1 query patterns and missing index warnings.

---

Script Debugger (Server-Side Breakpoints)

For complex Business Rules and Script Includes, use the server-side Script Debugger:

System Diagnostics → Script Debugger

1. Add a debugger; statement in your server-side script
2. Open the Script Debugger in a separate tab
3. Trigger the script execution
4. The Debugger pauses at your breakpoint and shows:
   • Current variable values
   • Call stack
   • Step over / step into controls

This is the most powerful tool for understanding exactly what's happening inside a Business Rule.

---

System Logs

System Logs → Application Log
System Logs → System Log

All gs.info(), gs.warn(), gs.error() output appears here. Filter by:

• Message: Search for your log output
• Level: Error/Warning/Info
• Created: Time range
• Source: Your script name

Best practice: Every Business Rule and Script Include should have meaningful gs.info() statements at key decision points — not for production verbosity, but to enable debugging without code changes:

gs.info('IncidentPriorityBR: Fired for ' + current.getValue('number') + 
        ' | Priority: ' + current.getValue('priority') + 
        ' | Previous: ' + previous.getValue('priority'),
        'IncidentPriorityBR');

---

Stats.do — Instance Performance

Navigate to <instance>.service-now.com/stats.do for a real-time view of instance health:

• Active sessions
• Transaction queue depth
• Slow query log
• Memory usage
• Scheduler status (for scheduled jobs)

If your instance is responding slowly, stats.do often shows the cause — a backed-up transaction queue, memory pressure, or a specific slow query.

---

Thread Debug — Finding Runaway Scripts

System Diagnostics → Session Debug → Transactions → Stats.do

In stats.do, click Threads to see currently executing transactions. A thread stuck at 100% CPU running the same script for minutes indicates a runaway loop or deadlock.

---

Diagnosing Common Issues

Business Rule Not Firing

Checklist:

1. Is the rule Active? ✅
2. Does the Table match exactly (check for table inheritance issues)?
3. Does the Condition evaluate to true for your test record?
4. Enable Business Rule session debug and check the output
5. Check for a higher-priority rule calling current.setAbortAction(true)

Client Script Not Firing

Checklist:

1. Is the Script Active? ✅
2. Does the Table match?
3. For onChange: is the Field name correct?
4. Is isLoading check preventing execution?
5. Open browser DevTools → look for JavaScript errors

ACL Denying Access Unexpectedly

Checklist:

1. Enable Security session debug
2. Navigate to the record and perform the action
3. Read the debug output — it lists exactly which ACL denied access and why
4. Check if the user has the required role
5. Check if the script's answer variable is being set correctly

Scheduled Job Not Running

Checklist:

1. Is the job Active? ✅
2. Check the Next run time — is it in the past?
3. Check stats.do → Scheduler tab — is the scheduler running?
4. Review the Job's execution history for error messages

---

Best Practices

• Add gs.info() log statements at decision points in all Business Rules during development
• Remove or reduce logging before deploying to production (use a log level property)
• Use Session Debug for targeted investigations — disable when done
• Bookmark stats.do for quick instance health checks
• When debugging ACL issues, always use Security Session Debug rather than guessing
• Use the Script Debugger for complex multi-step server-side logic
• Check System Logs immediately after deploying a new Business Rule to catch early errors

---

Conclusion

Debugging is a skill that separates average developers from exceptional ones. The platform provides every tool you need — session debug for real-time visibility, the Script Debugger for step-through analysis, system logs for historical records, and stats.do for performance diagnostics. Build the habit of knowing which tool to reach for first, and you'll spend far less time puzzling over mysterious platform behavior.