How to Troubleshoot a Slow ServiceNow Instance

// This runs against millions of records
var gr = new GlideRecord('cmdb_ci');
gr.query(); // No filter!
while (gr.next()) { ... }

The diagnostic sequence for a slow instance

When your instance is slow, diagnose in this order rather than guessing. First: check the System Diagnostics > Stats page — it shows current memory usage, active database connections, and thread count. High memory or high thread count indicates an active load problem. Second: check the Slow Query Log (System Diagnostics > Stats > Database) for recent queries over 1 second. Third: check the Currently Executing Transactions to see what is running right now. Fourth: check for Scheduled Jobs that may be running unexpectedly — a runaway job can saturate instance resources. Fifth: check the System Log for errors in the last 15 minutes — sometimes a failing script loop causes performance degradation before it errors out.

Common root causes by symptom

• Slow on one specific form/record — a Business Rule or ACL script on that table is expensive. Use Session Debug to trace which rules are running on that form.
• Slow across all list views — a query missing an index, or a table scan on a large table. Check the slow query log for the list view queries.
• Slow only during business hours — user load is the variable. Profile with stats.do during peak and off-peak to identify load-sensitive queries.
• Suddenly slow after a change — a recently committed Update Set introduced the problem. Check the Update Set history for changes in the past 24 hours and test rolling back the suspect change on a clone.

Related: Instance Scan · GlideRecord performance · Business Rules · RaptorDB

Performance baselines — why you need them before incidents

Troubleshooting "the instance is slow" without baseline performance data is guesswork. Before a problem occurs, establish what normal looks like: average page load times during business hours, typical database query counts per minute, normal memory consumption range. ServiceNow's Stats page (stats.do) and the Performance overview on the instance dashboard show these metrics — screenshot them during normal operation and save them. When someone reports slowness, you can immediately compare current stats against your baseline rather than trying to judge performance without reference points.

The role of RaptorDB in performance

If your instance is on RaptorDB, some performance issues that used to require query optimisation may now resolve without code changes — the column-store index handles aggregation queries dramatically faster than MariaDB did. However, RaptorDB does not fix application-layer performance issues: Business Rules that call GlideRecord in loops, Client Scripts that make unnecessary server round trips, and ACL scripts that run expensive queries still degrade performance regardless of the database engine. RaptorDB raises the ceiling; good scripting practice determines how close you get to it.

Reading the Thread and Transaction Logs

ServiceNow instances expose performance data through several log sources. The Transaction Log (syslog_transaction) records every server-side transaction with its execution time, SQL time, and script execution time. Sorting this table by total transaction time descending, filtered to the last hour, surfaces the slowest operations in your instance right now. The distinction between SQL time and script time matters: high SQL time points to inefficient GlideRecord queries or missing database indexes, while high script time points to expensive Business Rules, Client Scripts, or Script Includes that need optimisation. A transaction with 5 seconds total time but only 200ms SQL time has a scripting problem, not a database problem.

Node Diagnostics and Memory Pressure

In clustered instances, performance problems are sometimes node-specific rather than instance-wide. The Node Diagnostics page (accessible via System Diagnostics) shows per-node thread pool utilisation, memory consumption, and garbage collection activity. A node running at 95% thread utilisation while others are at 40% indicates uneven load distribution, often caused by sticky sessions routing disproportionate traffic to one node. A node with abnormally high garbage collection frequency is under memory pressure — usually from large in-memory objects being created in scripts (such as arrays built by iterating GlideRecord result sets without using GlideAggregate for aggregation).

Slow Client Script Diagnosis

Client-side performance issues manifest differently from server-side ones — they appear as sluggish form loading, UI interactions that feel delayed, or browser tab CPU spinning. Browser developer tools are the starting point: the Network tab shows how long each server call takes, and the Performance tab identifies JavaScript execution bottlenecks. On the ServiceNow side, onLoad Client Scripts that run synchronous GlideAjax calls block the form from rendering until the call completes. Converting synchronous GlideAjax calls to asynchronous callbacks is one of the highest-leverage performance fixes available for form-heavy customisations. The GlideAjax guide covers the async conversion pattern in detail.

Scheduled Jobs and Background Processing Bottlenecks

Performance degradation that appears cyclically — at the same time each day or week — is usually caused by resource-intensive Scheduled Jobs competing with user traffic. The Scheduled Job Execution History shows exactly when jobs run and how long they take. Jobs that process large datasets synchronously during business hours are the primary culprits. The remediation strategy is to shift heavy jobs to off-peak windows, break large jobs into smaller batches processed across multiple runs, or rewrite the job logic to use GlideAggregate instead of iterating individual records where only aggregate data is needed. The Instance Scan check for unbounded queries in Scheduled Jobs will flag the worst offenders automatically.

Import Sets and Integration Load

Large Import Set loads are a common source of instance slowness that is often overlooked during performance investigations. An Import Set processing 100,000 rows with a complex Transform Map that triggers Business Rules on each row can saturate the instance's processing capacity for extended periods. The key diagnostic is checking the Import Set Run table during the slowdown window — if large imports correlate with the performance degradation, the solution is to move imports to off-peak hours, increase batch size for imports that have low per-row transform complexity, or add g_transform.abort() guards to skip unchanged records and reduce unnecessary processing.

Quick Diagnostic Checklist

When an instance slowdown is reported, a systematic 10-minute diagnostic covers the most common causes. Check the Transaction Log for high-duration transactions in the last 30 minutes — identifies which specific operations are slow. Check the Node Diagnostics page for thread pool and memory pressure — identifies whether this is a capacity issue. Check the Scheduled Job Execution History for jobs running during the slowdown window — identifies background processing competition. Check recent deployments and Update Set commits from the last 24 hours — identifies whether a recent change introduced a performance regression. This four-step sequence resolves most reported slowness incidents without needing specialist knowledge, and each step takes less than two minutes if you know the navigation path. Bookmark the Transaction Log and Node Diagnostics pages for fast access during incidents. The Instance Scan guide covers how to prevent the most common causes from being introduced in the first place.

Engaging ServiceNow Support Effectively

When internal investigation exhausts the common causes and the instance remains slow, a support case with the right information accelerates resolution. Capture the Transaction Log records from the slow period (export to CSV), note which node was reporting high utilisation from Node Diagnostics, and document whether the slowness is user-reported across all users or isolated to a specific module or operation. This information lets support engineers skip the diagnostic questions they would otherwise ask and move directly to analysis. For critical production slowness, request the case be handled as a Priority 1 and follow up by phone rather than waiting for email responses. Platform-level issues (infrastructure problems, node imbalance, database issues) that the instance team cannot fix internally are resolved faster when support has complete diagnostic data from the moment the case is opened.

Performance Profiling with the Stats Page

The ServiceNow Stats page (append /stats.do to your instance URL) provides a real-time snapshot of instance activity: active threads, recent transaction counts, memory heap usage, and database connection pool status. It requires admin access and is the fastest way to assess overall instance health in the moment a slowdown is reported. A healthy instance shows thread utilisation below 70%, heap memory below 80%, and no transaction queue buildup. Elevated heap memory with frequent garbage collection cycles (visible in the stats page as GC pause times) indicates memory pressure that will progressively degrade response times. A growing transaction queue where inbound requests arrive faster than threads can process them indicates either a resource capacity issue or a spike of long-running transactions blocking the pool. Both patterns require different remediation: the first needs memory or optimisation; the second needs the long-running transactions identified and resolved.