ServiceNow Troubleshooting Guide: Fixing 'Transaction cancelled' and Instance Timeouts

Understanding the Error: ServiceNow Performance and Stability

When users report "ServiceNow not working" or experience a complete "ServiceNow crash," the root cause rarely lies in the underlying infrastructure, as ServiceNow is a heavily managed and resilient SaaS platform. Instead, catastrophic failures, "ServiceNow slow performance," and "ServiceNow timeout" errors are almost always the result of a sub-optimal ServiceNow configuration, runaway server-side scripts, or poorly optimized database queries.

In an enterprise environment, a comprehensive ServiceNow troubleshooting guide must focus on isolating the specific transaction or node causing the degradation. The most common exact error messages you will encounter include:

• Transaction cancelled: maximum execution time exceeded
• java.net.SocketTimeoutException: Read timed out (Common during REST/SOAP integrations)
• Default quota rule: REST API - maximum execution time exceeded
• Syntax Error or Access Rule Violation detected in System Logs.

These symptoms frequently occur during heavy ServiceNow data migration tasks, when improperly coalesced Transform Maps lock database tables, or when poorly written before query Business Rules force full database table scans across millions of task records.

Step 1: Diagnose the Root Cause

Before making changes to your ServiceNow configuration, you must identify whether the issue is instance-wide (node resource exhaustion) or transaction-specific (a single bad query).

1. Check Node Health (stats.do) If the instance feels like it's experiencing a "ServiceNow crash" (yielding 502 Bad Gateway errors or a completely unresponsive UI), navigate to https://<your-instance>.service-now.com/stats.do. Look closely at the System Memory and Active Semaphores. If free memory is consistently below 10% or all default semaphores are locked in use, a runaway script or massive data pull is hogging the JVM.

2. Analyze Active Transactions Navigate to User Administration > Active Transactions (All nodes). Sort the list by the Execution Time column. Look for transactions running longer than 300 seconds. If you see UI actions, scheduled jobs, or REST API calls stuck here, this is the direct source of your "ServiceNow timeout" errors.

3. Review the System Log and Node Logs Go to System Logs > Errors. Search for the keywords SQL or Slow Query. During a complex ServiceNow data migration, if you see java.sql.BatchUpdateException, your transform map is hitting a strict database constraint, an unmapped reference field, or a data truncation issue.

Step 2: Implement the Fix

Scenario A: Fixing "ServiceNow Slow Performance" due to Bad Queries

If your diagnostics reveal slow database queries, the issue is often an unindexed field being used in a GlideRecord query or a Transform Map coalesce field.

• Fix: Navigate to System Definition > Tables, select your target table, and ensure the fields used in your addQuery() statements have a dedicated Database Index.
• Code Review: Never use .chooseWindow() without an accompanying .orderBy(). Furthermore, ensure .setWorkflow(false) and .autoSysFields(false) are utilized during massive server-side data updates to prevent triggering cascading Business Rules that multiply the transaction load.

Scenario B: Resolving "ServiceNow Timeout" in Integrations

Timeouts during inbound REST APIs often happen because the JSON payload is too large or the resulting Business Rules take too long to execute synchronously.

• Fix: Implement strict pagination. Break down large ServiceNow data migration payloads into chunks of 1,000 records or less.
• Configuration: Adjust the Transaction Quota Rules (System Maintenance > Transaction Quota Rules) only if absolutely necessary for a specific service account. Prefer optimizing the script over extending the timeout quota, as extending quotas just delays inevitable memory exhaustion.

Scenario C: Halting a "ServiceNow Crash" or Hang

If a poorly tested background script is bringing down the primary application node:

• Fix: Navigate to System Diagnostics > Active Transactions, right-click the offending transaction, and select Kill. If the UI is completely unreachable, utilize the server-side console if available via your MANAGE portal, or raise an emergency P1 ticket with ServiceNow HI Support to restart the specific application node.

Best Practices for ServiceNow Configuration

1. Client-Side: Minimize GlideAjax synchronous calls in onChange client scripts. Use g_scratchpad via Display Business Rules to load necessary relational data when the form initially loads.
2. Server-Side: Always limit GlideRecord queries with .setLimit(1) when expecting a single result. Never query large tables without at least one indexed filter condition.
3. Integrations: Always use asynchronous Business Rules (async) or Flow Designer background processes for outbound integrations to prevent blocking the user's UI thread and causing perceived "ServiceNow not working" symptoms.