Troubleshooting a slow transactionIssue <!-- /*NS Branding Styles*/ --> .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: ; } } If a UI transaction takes longer to complete than expected, this article provides three options for identifying the cause. The investigation can focus on the slow area of the platform — whether ACLs, business rules, database, or client-side — using timings recorded in Filter Navigator > System Logs. If a user triggers a transaction that executes for a long time, the transaction quota rule cancels the transaction after 5 minutes (default). A warning message similar to Your transaction has been cancelled with a reason of Maximum execution time exceeded may appear. Use the following steps to investigate. Note: These steps must be followed on the same node (for example, reproduction of the slow transaction and the subsequent node log file review). Only transactions with a response time >100ms appear in the logs. To see all database queries, enable additional debugging via Filter Navigator > Debug SQL detailed. This article outlines three options for investigating slow performance: - Option 1 (quickest method): Debug Module in the UI — quick and straightforward when reproducing a specific session or transaction. This option can also lead into the Index Suggestion Engine. - Option 2A: Node Log file browser — more steps but a flexible approach, as any entry in the log can be analysed. - Option 2B: Download the localhost_log file to a local workstation and use a text editor to interrogate the logs further. Release<!-- /*NS Branding Styles*/ --> .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: ; } } All currently supported versions. Resolution<!-- /*NS Branding Styles*/ --> .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: ; } } Option 1: Session debug (quickest method) Use the steps below or follow along with this video to troubleshoot a slow transaction with the Session Debug feature. 1. Filter Navigator > System Diagnostics > Session Debug > Enable All (this opens a debugging tool in a new window)2. Reproduce the transaction3. Review the output in the session log window The session log includes useful features: the log can be downloaded, cleared, or filtered to remove noise from the output screen. Search for the word EXCESSIVE in the log output — these are the slow queries that need to be investigated. If an expensive SQL query is present (for example, one taking 8.459 seconds), the index suggestion feature can be used: 1. In the main UI window where the transaction was reproduced, scroll down to the debug output under the **Query** header.2. Open the record for the expensive query — this opens a record in the slow query module.3. Follow the steps in [How to create indexes using the Index Suggestion Engine (ISE)](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0782916) KB0782916. Option 2A: Node log file browser 1. Reproduce the slow transaction.2. Navigate to Filter Navigator > System Logs > Transactions (All user).3. Personalise the columns on the list. The following columns are useful to add: - Browser time - Business rule time - Client network time - Client response time - Client script time - Network time - Semaphore wait time - Session - Session wait time - Session ID - Total wait time - Total page load time - Total wait time - Transaction Number - Transaction processing time - UI policy time 4. Amend the list condition filter to **created_by** = <affected_user> and sort by **created** desc. This filters out noise and focuses on the affected user only.5. Identify the slow transaction in the transaction log — the URL column shows the transaction type. The slow transaction should appear near the top of the list.6. Copy the **SessionID** (session column) and **Transaction Number** of the problem transaction.7. Navigate to Filter Navigator > Node Log File browser.8. Amend the **Start time** and **End time** fields to encompass the time the problem transaction was executed.9. Set the following fields: - Session ID = (paste the **SessionID** from step 6) - Max rows = 10000 - Message = (paste the **Transaction Number** from step 6)10. Select Submit. This displays the targeted transaction.11. Copy the **txid** value from the affected transaction log output, for example **txid**=81c8704bdbc7. Searching by **txid** instead of just the **SessionID** returns more detail about the user transaction. 12. Keep the log file parameters the same, but replace the **Transaction Number** in the message field with the **txid** value. Select Submit. The steps above provide the transaction of interest with extra detail. For example: - The transaction was a mytable_list.do- The database query (SELECT) took 13.604 seconds (Time:0:00:13.604)- The log entry with EXCESSIVE ***END shows the part of the platform accounting for most of the time. In this example, 13.737 is the *total time* and *SQL time* is 13.611, meaning the vast majority of time is spent at the SQL (database layer). Looking at the query itself, the issue is apparent: the query has no WHERE clause, which means the platform must retrieve all records from the table. This is not efficient at scale and cannot use a database index. A filter condition should be added to retrieve a smaller result set. The next example shows the same list view transaction with a filter condition mycolumn='ABCD'. The query is still slow at 15 seconds even with the filter condition. This indicates that an index on the mycolumn column may be needed to make the condition effective. After adding an index on MyTable(MyColumn) via the UI, looking at the transaction again shows that the SQL query no longer appears in the logs. This is because it now executes faster than 100ms and is therefore not logged. SQL time is now very fast at 73ms. Option 2B: Node log file download 1. Reproduce the slow transaction.2. Navigate to Filter Navigator > Node Log File Download.3. Amend the list condition to show only records where **Name** starts with localhost.4. Sort by Name in descending order.5. The file at the top of the list is today's localhost log file.6. Open the record.7. Select Download log. Use a text editor of choice to search and interrogate the logs. Search using the **SessionID** (session column) and **Transaction Number** to locate the relevant transactions. The **txid** value can also be used to search if available. --- Next steps The focus of investigation should follow where most of the transaction time is spent. If most time is spent processing ACLs, that area should be the focus. If UI Action time is high, UI Actions should be investigated. If SQL time is highest, the database queries need to be reviewed. If SQL time accounts for the majority of the transaction time, answer the following questions: 1. Does the query have a condition filter (a WHERE clause)? If so, is the condition filter efficient? See **Performance Best Practice for Efficient Queries** in the additional information section of this KB. 2. Is the data result set scoped to a small or limited subset of data (for example, using active=1 or a date range)? If not, consider adding active=1 or a date range to reduce the result set. 3. Would the query benefit from an index hint or index? Depending on the columns and logic operands after the WHERE clause, an index may help. If Option 1 was followed, the [Index Suggestion Engine article](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0782916) KB0782916 can be used to try an index easily. 4. Remember to test any new indexes in a recently cloned instance before applying them in production. Related Links<!-- /*NS Branding Styles*/ --> .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: ; } } More information about the Session log can be found in the Script Debugger and Session Log ServiceNow Product Documentation.More information about adding an index can be found in the Creating Tables ServiceNow Product Documentation.More information about Client Transaction timings can be found in the Client Transaction Timings ServiceNow Product Documentation.Resources for for most common, high-impacting Performance issues on ServiceNow instances can be found at KB0829067 - Performance Landing Page.KB0755706 - What is Session wait / Session Synchronization?KB0782916 - How to create indexes using the Index Suggestion Engine (ISE)KB0634588 - Six common performance pitfalls in Service Portal and how to avoid themServiceNow Community: Performance Best Practice for Efficient Queries - TOP 10 practicesServiceNow Community: Recommendations for Optimal Instance Performance