Inbound Web Services — Timeouts and Slow Responses - Support and Troubleshooting

Inbound Web Services — Timeouts and Slow Responses .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Contents Issue Quick Triage Where Time Goes — Query Anatomy Diagnostic Decision Tree Five Causes — Diagnosis and Fix 5.1 Server Exception (HTTP 500) 5.2 Per-Table Transaction Quota (5-Minute Cancellation) 5.3 Slow Query (Missing Index or Unfiltered Query) 5.4 HTTP 202 — Session Reuse Queue Overflow 5.5 HTTP 499 — Client Closed the Connection What to Capture Before Opening a Case Common Misconceptions Related Articles 1. Issue Inbound web service calls that succeed eventually but take much longer than expected, time out without a clean 429, or return an unexpected status code. This article covers diagnosis and resolution for slow calls, timeouts, and related response anomalies. For throttling-related 429s, see Inbound Web Services — Rate Limits and Throttling .

Symptoms covered:

Inbound Table API or Scripted REST calls take 30 seconds or longer when they used to complete in under 5. Calls cancel at almost exactly 5 minutes (300 seconds). HTTP 500 with a stack trace in the response or System Log. HTTP 202 — request accepted but not processed; integration reusing a session while calls queue faster than they are consumed. HTTP 499 — the client closed the connection before the instance finished responding. HTTP 502 — node unresponsive or high load, or customer-side proxy issue. Intermittent 503 that resolves on retry. Calls slow down progressively over a day before recovering after a maintenance window. ↑ Back to top

2. Quick Triage 30-second routing:

HTTP 500 with stack trace? Server exception. Jump to Section 5.1 . Cancels at exactly 5 minutes? Per-table transaction quota. Jump to Section 5.2 . Slow but completes? Likely missing index or unfiltered query. Jump to Section 5.3 . HTTP 202? Session reuse with queuing overflow. Jump to Section 5.4 . HTTP 499? Client closed the connection before the instance finished. Jump to Section 5.5 . Intermittent 502 / 503? Usually transient. Retry with backoff; investigate only if sustained. ↑ Back to top

3. Where Time Goes — Query Anatomy Customers reporting slow inbound calls usually suspect the network. Almost every time, the actual time is spent in the database. The breakdown below is typical for an inbound Table API GET against a large table:

Key takeaway: diagnosing a slow inbound call means investigating the query and the data, not the connection.

↑ Back to top

4. Diagnostic Decision Tree Walk the tree from the top. The branch you land on names the most likely root cause.

↑ Back to top

5. Five Causes — Diagnosis and Fix 5.1 Server Exception (HTTP 500) Signature: response includes HTTP 500 and often a stack trace. System Log ( syslog ) contains the matching exception.

Common causes:

Scripted REST endpoint script throws an uncaught error. Business rule on the target table errors out during ACL evaluation or before-insert logic. JVM out-of-memory on the node serving the call. Platform-side issue (rare; if reproducible across two nodes and not your code, treat as PRB candidate). Fix: retrieve the stack trace from System Log filtered to the failure timestamp. Fix the script or business rule that threw. If the trace shows platform code, open a case with the trace, the request, and the node hostname.

↑ Back to top

5.2 Per-Table Transaction Quota (5-Minute Cancellation) Signature: call cancels at almost exactly 300 seconds. May surface as a 429 or 5xx depending on where in the lifecycle the cancellation occurred.

Why this happens: the default REST/JSON catch-all transaction quota is 300 seconds. The platform cancels any query that exceeds it.

Fix order, lowest effort first:

Filter the query. Add a tight sysparm_query — especially on indexed fields. Querying a 5-million-row table with no filter is the most common cause. Paginate. Use sysparm_limit + sysparm_offset to split a large read into multiple calls. Start at 1000 records per page. Reduce returned fields. Use sysparm_fields to limit columns. Helps when the response includes large reference resolutions. Shift to off-peak. If the query is large but defensible, move it to a low-traffic window. Request a quota review. If the business case requires longer transactions, open a HI ticket with the transaction profile and justification. For more on quotas, see Inbound Web Services — Rate Limits and Throttling , Section 7.

↑ Back to top

5.3 Slow Query (Missing Index or Unfiltered Query) Signature: call completes but takes much longer than expected. No timeout, no 5xx. Latency is consistent — it is not transient.

Common causes:

A custom field used in sysparm_query has no index. The database scans every row. The filter is on a journal field, dot-walked reference, or scripted condition that cannot use an index. Reference resolution is pulling in large child tables — use sysparm_exclude_reference_link=true . Business rules or query business rules add work per row. Fix:

Inspect the filter fields. Confirm every field in sysparm_query has an index ( System Definition → Database Indexes ). Add the missing index. If a custom field is used in production integrations, it should be indexed. Coordinate with the platform admin before adding indexes on large tables. Watch in real time. Open stats.do while a slow call is running — the in-use semaphore row will name the active transaction and its elapsed time. Check System Log for slow query warnings. The platform logs queries exceeding internal thresholds. Filter on the integration user and the time window. Trim the response. sysparm_fields reduces serialization time. sysparm_exclude_reference_link=true skips reference URL construction. ↑ Back to top

5.4 HTTP 202 — Session Reuse Queue Overflow Signature: the instance returns HTTP 202 Accepted. The request was not processed and should be retried. No error is raised, but the expected operation did not complete.

Why this happens: HTTP 202 occurs when a web service reuses the same session and incoming requests arrive faster than they can be processed. Too many requests for the same session are queued, causing new requests to be returned with a 202 status code. Unlike a 429, the platform is not rejecting the call due to a rate limit — it is deferring it because the session queue is full.

Fix:

Do not treat 202 as success. Implement client-side retry logic that detects 202 and retries the request after a short delay. Reduce the rate at which the integration submits requests on the same session. Use connection pooling with multiple sessions to distribute load. Check syslog_transaction for the corresponding time period to identify the session and the queue depth at the time of the 202. ↑ Back to top

5.5 HTTP 499 — Client Closed the Connection Signature: the load balancer records a 499 status code. The client receives no response or a timeout error. On the instance side, the node may have continued processing and completed successfully — but the client had already given up.

Why this happens: HTTP 499 is issued by the ServiceNow ADC (load balancer) when the client closes the TCP connection before the node finishes processing. This is not a server error. The instance may have completed the request correctly — the client just did not wait long enough.

Two scenarios:

Client timeout too short: the client’s read or connection timeout is shorter than the time the instance needs to process the request. Extend the client timeout. Instance genuinely slow: the instance is not completing the request within a reasonable time. The 499 is a symptom of a deeper performance problem — investigate using Sections 5.2 or 5.3. Fix:

Check whether the instance actually processed the request by looking in the target table or System Log for an entry at the timestamp of the failure. If the record exists, the instance completed the operation — only the client missed the response. If the client timeout is too short, increase it. For REST calls, a 30–60 second read timeout is a reasonable starting point for most integrations. If 499s are occurring in bursts, check whether a client retry loop is compounding the problem: each retry re-queues work on the instance while previous requests are still running. ↑ Back to top

6. What to Capture Before Opening a Case If self-diagnosis does not resolve it, gather the following before opening a support case. These items resolve most cases at first touch.

The exact request — full URL including all sysparm_* parameters, method, and (if POST/PUT) payload size and a redacted sample. Time of failure to the second, with timezone (UTC preferred). Target table and approximate row count. Integration user and roles assigned to that user. Performance metrics from the transaction log (where available): session wait time, semaphore wait time, total wait time, business rule time, ACL time, SQL time, CPU time, response time, transaction processing time. A snapshot of https:// .service-now.com/stats.do captured during or immediately after the slow call. Stack trace from System Log, if HTTP 500. Recent change context — platform upgrade, schema change, new business rule, or client deployment in the last 30 days. ↑ Back to top

7. Common Misconceptions “The network is slow.”

Almost never. About 75% of slow-call time is database execution (see Section 3 ). Network is typically under 5%.

“Adding nodes will make it faster.”

Adding nodes increases concurrent capacity (more simultaneous calls), not the speed of any single call. A slow query stays slow on more nodes.

“The 5-minute timeout is configurable on the client.”

No. The 300-second cancel is enforced by the platform, not the client. Increasing your client timeout has no effect — the platform cancels first.

“A bigger sysparm_limit returns the data faster.”

The opposite. Larger sysparm_limit means longer single transactions, which are more likely to hit the 5-minute quota. Smaller pages, more calls is the right tradeoff.

“A 500 means the platform is broken.”

Usually customer-side: a scripted endpoint script, a business rule, or an OOM caused by an oversized payload. Platform-side 500s exist but are the exception. Get the stack trace first.

“HTTP 202 means the request was accepted and will be processed.”

In standard HTTP, yes. In this ServiceNow pattern, 202 means the session queue was full and the request was deferred — it may never be processed unless the client retries.

↑ Back to top

8. Related Articles Inbound Web Services — Troubleshooting Guide (hub) Inbound Web Services — Rate Limits and Throttling Inbound Web Services — No Response and Connection Failures Inbound Web Services — Authentication and Authorization Failures Inbound Web Services — Empty or Incomplete Results KB0998504 — Capturing localhost logs for inbound web service issues KB2628639 — Table API response sorting behavior KB0547836 — Web service export sizing and throttling ↑ Back to top