Handling Common API Errors and Timeouts When Connecting to ServiceNow

Integrating PowerShell with the ServiceNow Table API mostly works — right up until a large table like incident, task, or cmdb_ci throws something unexpected: a script that crashes with no clear reason, a response that's missing fields you expected, or a call that just times out. This article covers the real causes behind the most common failures, and — just as importantly — the actual HTTP behavior involved, since getting that wrong leads to error-handling code that silently doesn't work.

Problem 1: "Transaction Cancelled – Maximum Execution Time Exceeded"

This happens when the server-side query takes too long to process — commonly on large tables, broad queries, or when heavy business logic runs on every matched record. The actual response comes back as HTTP 500 Internal Server Error, with this JSON body:

{
  "error": {
    "message": "Transaction cancelled: maximum execution time exceeded",
    "detail": "Transaction cancelled: maximum execution time exceeded Check logs for error trace or enable glide.rest.debug property to verify REST request processing"
  },
  "status": "failure"
}

This comes back as a real HTTP 500 error, not a 200. That distinction matters for how you handle it in PowerShell, covered in Problem 3 below. The default timeout is controlled by the glide.rest.max_execution_time_in_seconds property (60 seconds out of the box).

Why This Happens

• You're pulling too many records at once.
• Filters use unindexed or dot-walked fields (see Problem 2).
• Long-running Business Rules or Flows are slowing down the underlying query.
• You forgot to paginate or narrow the date range.

Fix It With PowerShell

# Correct use of pagination and fields
$limit = 100
$offset = 0
$url = "https://$instance.service-now.com/api/now/table/incident?sysparm_limit=$limit&sysparm_offset=$offset&sysparm_fields=number,short_description,state"

$response = Invoke-RestMethod -Uri $url -Headers $headers
$response.result

Tip: always use sysparm_limit, sysparm_offset, and sysparm_fields together to reduce payload size and processing time per request — smaller, paginated calls are far less likely to hit the execution time ceiling than one large unbounded query.

Problem 2: Dot-Walked Field Filters Kill Performance

A filter like this:

caller_id.department.name=Finance

...is slow and prone to timing out, because dot-walking through reference fields in a query introduces implicit joins under the hood. The deeper the dot-walk, the more expensive the query gets.

Fix

Use direct sys_id values instead of dot-walking through display names:

$filter = "caller_id=6816f79cc0a8016401c5a33be04be441"
$url = "https://$instance.service-now.com/api/now/table/incident?sysparm_query=$filter"

If you don't already know the sys_id you need, resolve it with a separate, targeted lookup first, rather than filtering the large table by a dot-walked value on every call.

Problem 3: Handling Real Errors in PowerShell Correctly

Since a timeout or server error comes back as a real HTTP 500 (or 400, 403, 404, depending on the failure), Invoke-RestMethod treats it as a terminating error by default in Windows PowerShell. That means an unhandled call doesn't quietly continue with an empty result — it stops your script entirely at that line, which is its own problem if you're not expecting it.

Add Proper Error Handling

try {
    $response = Invoke-RestMethod -Uri $url -Method Get -Headers $headers -ErrorAction Stop
    Write-Host "✅ Records returned: $($response.result.Count)"
}
catch {
    $statusCode = $_.Exception.Response.StatusCode.value__
    $errorBody = $_.ErrorDetails.Message
    Write-Host "❌ API call failed with status $statusCode"
    Write-Host "Details: $errorBody"
}

On PowerShell 7+, Invoke-RestMethod also supports -SkipHttpErrorCheck, which lets you inspect $response.StatusCode directly without throwing — useful if you want to branch on specific status codes without a try/catch block:

$response = Invoke-RestMethod -Uri $url -Headers $headers -SkipHttpErrorCheck -StatusCodeVariable statusCode
if ($statusCode -ne 200) {
    Write-Host "❌ API Error ($statusCode): $($response.error.message)"
} else {
    Write-Host "✅ Records returned: $($response.result.Count)"
}

Problem 4: A 200 That Still Isn't What You Expected

There is a real scenario where a genuinely successful 200 OK response doesn't give you what you expected: Access Control Rules silently filtering data out of the response. If the account making the API call doesn't have read access to certain fields or records, ServiceNow doesn't return an error for that — it simply omits or blanks out what the caller isn't allowed to see. The call succeeds, the status is 200, and the response can still look "off" — fewer records than expected, or fields present in the schema but empty in every row.

If a script consistently returns fewer records or thinner data than expected with no error at all, checking the calling account's role and ACL access on the target table is usually a faster diagnosis than assuming it's a scripting bug.

Extra Debugging Tools

• Enable REST logs in ServiceNow. Set glide.rest.debug = true temporarily (turn it back off afterward — this is verbose and not meant to run permanently).
• Check syslog for REST errors. Navigate to System Logs > Errors.
• Use Postman to isolate the failure. If a call fails from PowerShell but succeeds with identical parameters in Postman, the problem is in your PowerShell handling — headers, encoding, or error handling — not the API call itself.

Conclusion

Performance and error handling both matter here, but get the mechanics right first: ServiceNow's REST Table API returns real, standard HTTP status codes for real errors — it doesn't hide a 500-level failure behind a 200. The practical risk in PowerShell isn't a disguised error slipping past your checks; it's an unhandled terminating exception stopping your script cold, or an ACL quietly limiting what a 200 actually contains. Handle both, and paginate your queries with sysparm_limit/sysparm_offset/sysparm_fields, and most of what shows up here goes away.