ServiceNow Configuration Troubleshooting Guide: Fix Crashes, Timeouts, Slow Performance & Migration Errors

Understanding ServiceNow Configuration Errors

ServiceNow is a multi-tenant, Java-based SaaS platform running on Glide (its proprietary application framework). Most configuration problems manifest in one of four areas: scripting runtime, database layer, import/transform pipeline, or node JVM health. Understanding which layer is failing dramatically shortens mean time to resolution.

When ServiceNow is not working, the platform surfaces errors in three primary locations:

• sys_log table (All > System Logs > System Log > All)
• Node log files at /var/log/servicenow/<instance>/ (on-prem) or via HI portal for cloud
• Browser console (F12) for client-side script errors

Always check all three before assuming a root cause.

Step 1: Diagnose — Identify the Failure Layer

1a. Check Active Transactions for Runaway Scripts

Navigate to System Diagnostics > Active Transactions. Look for transactions with elapsed time >30 seconds or CPU >80%. Common culprits display as:

URL: /api/now/table/incident
Script: GlideRecord query on cmdb_ci (no index on u_custom_field)
Elapsed: 142s | CPU: 98%

Click the transaction row and select Cancel Transaction to immediately free the thread. This does not fix the root cause but stops the bleeding.

1b. Parse the System Log for Error Patterns

Filter sys_log by level = error and sys_created_on > [last 1 hour]. Key error signatures to recognize:

• Transaction cancelled: maximum execution time of 30 seconds exceeded → Script timeout; check Business Rules and Script Includes on the affected table
• GlideRecord: query requires table scan → Missing index; note the table and field name
• Java heap space or OutOfMemoryError → Node memory exhausted; requires JVM tuning or node restart
• Import set transform failed: coercion error on field [field_name] → Type mismatch in Transform Map field mapping
• Deadlock detected on table [table_name] → Concurrent write conflict; check scheduled jobs overlapping

1c. Check Node Health via Stats

Navigate directly to https://<instance>.service-now.com/stats.do. This endpoint returns raw JVM and thread statistics without requiring a license. Key metrics:

• memory.heap.used / memory.heap.max — if ratio >0.85, the node is memory-pressured
• thread.count.active — values persistently >200 on a single node indicate thread starvation
• db.pool.size / db.pool.active — if active approaches pool size (default 40), database connections are exhausted

1d. Identify Slow Queries

Navigate to System Diagnostics > Stats > Slow Queries or query sys_log_stats directly:

SELECT table_name, query_count, avg_duration_ms, max_duration_ms
FROM sys_log_stats
WHERE avg_duration_ms > 5000
ORDER BY max_duration_ms DESC
LIMIT 25;

On cloud instances, use the Performance Analytics module or the Slow Query Analyzer plugin (com.glide.slow_query_analyzer) instead of direct DB access.

Step 2: Fix — Resolve by Layer

Layer A: Scripting Runtime Fixes

Timeout errors in Script Includes: Open the Script Include via System Definition > Script Includes, locate the offending script from the sys_log error, and add execution guards:

// Anti-pattern: unbounded GlideRecord loop
var gr = new GlideRecord('cmdb_ci');
gr.query(); // Full table scan on 500k records
while (gr.next()) { ... }

// Fix: add encoded query and limit
var gr = new GlideRecord('cmdb_ci');
gr.addQuery('operational_status', '1');
gr.setLimit(1000); // Prevent runaway
gr.query();
while (gr.next()) { ... }

For Business Rules, navigate to System Definition > Business Rules, filter by the affected table, and check When field. Business Rules set to before with complex queries on large tables are frequent timeout sources. Convert expensive logic to async Background Scripts where possible.

Layer B: Performance & Timeout Fixes

Increase script timeout for specific scopes (avoid global increase):

Navigate to System Properties (sys_properties.list) and modify:

• glide.script.timeout — default 30 (seconds); raise to 60 only for specific integration scopes
• glide.db.max_view_records — default 10000; reduce if list view queries are timing out
• glide.ui.list_edit.max_records — reduce from default 50 to 20 for tables >1M rows

Add missing database index:

1. Navigate to System Definition > Tables, open the affected table
2. Select the Database Indexes related list
3. Click New, select the column(s) identified in slow query logs
4. Set Unique only if the field has guaranteed cardinality
5. Save — ServiceNow creates the index asynchronously (monitor in System Diagnostics > Database > Indexes)

Layer C: Data Migration Fixes

Resolve Transform Map coercion errors:

Open the failing Transform Map (System Import Sets > Transform Maps). For each field showing coercion errors in the log:

1. Set Type explicitly (do not leave as Auto)
2. For reference fields, set Reference qualifier to restrict lookup scope
3. Add a Coerce field script for complex transformations:

// Coerce field script for date format mismatch
// Source: "23/02/2026" → Target: ServiceNow date format
answer = gs.dateGenerate(
  source.substring(6,10) + '-' +  // year
  source.substring(3,5)  + '-' +  // month
  source.substring(0,2),           // day
  '00:00:00'
);

For sys_id collision errors during migration (duplicate record errors), enable Coalesce on the sys_id or natural key field in the Transform Map field mapping. Coalescing forces an update rather than insert when a matching record is found.

Run a pre-flight validation: Before executing against production, use a Background Script to validate source data:

// Pre-flight: count import set records that will cause coercion failures
var gr = new GlideRecord('sys_import_set_row');
gr.addQuery('sys_import_set', 'YOUR_IMPORT_SET_SYS_ID');
gr.addQuery('sys_transform_map', 'YOUR_TRANSFORM_SYS_ID');
gr.addNullQuery('u_target_field'); // null reference fields
gr.query();
gs.info('Records with null reference: ' + gr.getRowCount());

Layer D: Node JVM Memory Fixes

For on-premise instances, edit /etc/service-now/<instance>/glide.properties:

glide.memory.max=4096
glide.memory.initial=1024
glide.db.pool.max=60

For cloud instances, open a HI (Hi portal) case requesting node memory profile review — direct JVM parameter access is not available. Provide the stats.do heap output as evidence.

After any node configuration change, flush the application cache via https://<instance>.service-now.com/cache.do (requires admin role) and monitor node restart progress in System Diagnostics > Node Log.

Step 3: Verify the Fix

1. Re-run the original failing operation
2. Check sys_log for recurrence of the error signature
3. Confirm stats.do shows heap ratio <0.75 and active DB connections <80% of pool
4. For data migration fixes, run the Transform Map against a 100-record test Import Set before full execution
5. Document the change in Change Management with before/after stats.do screenshots