SwissNowWhy is your ServiceNow instance slow?
"Slow" isn't one problem - it's several different layers, and most of the time nobody's separated them before trying to fix it. Here's how to actually find out.
"Slow" is at least five different problems
A single page load or transaction crosses several genuinely separate layers, and each one fails for a different reason. Fixing the wrong one is the single most common way a performance investigation goes nowhere.
Client rendering
Time spent in the browser itself - UI policies, client scripts, and rendering the page. Feels slow even when the server answered instantly.
Network round trip
Time the request and response spend in transit. Often the real culprit behind "it's slow for remote users" complaints that never show up for anyone on-site.
Server business logic
Business rules, script includes, and workflow/flow logic executing on the server before a response can be built.
Database
The actual SQL time - queries without a usable index, or a query pulling far more rows than the page needs.
Third-party integrations
An outbound REST or SOAP call made synchronously, inside the transaction, with no timeout - the whole page waits on someone else's API.
How to actually check, not guess
ServiceNow already tracks most of this - the diagnosis usually doesn't need a third-party tool.
Turn on Client Transaction Timings
If this platform plugin is active, every row in syslog_transaction carries a real millisecond breakdown across nine fields - client response time, client network time, browser time, client script time, UI policy time on the client side; server response time, network time, business rule time, and SQL time on the server side. That single row tells you which of the five layers above actually dominates, instead of guessing from a stopwatch.
Read syslog_transaction directly
Even without that plugin, transaction_processing_time and business_rule_count on the same table separate "the server was genuinely busy" from "something client-side is slow but the server answered fine."
For Next Experience / Workspace pages, check sys_client_interaction
A single page load can span several server transactions. This table gives you the whole-page picture instead - page load time, time to interactive, and a real UI cache-hit rate, not a guess at whether caching is even the issue.
The usual suspects
Once the layer is known, these account for most real-world slowness we see:
Root causes worth checking first
- Unindexed or unbounded
GlideRecordqueriesA query filtering on a field with no database index, or with nosetLimit(), pulling far more rows than the page actually shows. - Business rules with no conditionRunning on every insert or update on a busy table, including the ones it has nothing to do.
- Expensive ACL scripts on a list viewA script-based ACL condition gets evaluated once per row - on a 250-row list, that's 250 evaluations before the page can render.
- Chatty client scriptsA synchronous
GlideAjaxcall firing on every keystroke or field change instead of once, debounced. - Synchronous outbound integration callsA REST or SOAP call made inside a business rule with no timeout - if the other side is slow, so is every transaction that touches this record.
- Dot-walked reference qualifiersA reference field's qualifier that dot-walks through two or three other tables, re-evaluated every time the field is touched.
The manual version doesn't scale
None of this is complicated once you know where to look - but "once you know where to look" is doing a lot of work in that sentence. Someone still has to pull the transaction log, read the timing breakdown, form a hypothesis, and verify it - every single time a "the instance feels slow today" ticket comes in. It's real, recurring analyst time, and it's reactive by nature: nobody's looking until it's already someone's complaint.
Running this diagnosis continuously, automatically
Our own platform, neo.ai, runs exactly this diagnosis on a schedule - reading the same timing breakdown described above, and only escalating once the same root cause has genuinely recurred, not on a single one-off blip. It's one of seven categories it watches across a ServiceNow instance.