Troubleshooting Guide: Using the Transaction Logs

By observing the IP address field you can determine from what network a transaction originated. This information can be very helpful when diagnosing issues that seem to occur intermittently, impacting some users or regions, but not others. For example, the issue might occur when the user is logging on from within their corporate network, but not when logging in from their home network. Or perhaps performance issues are being reported by a certain user group located in the same geographic location. You might be able to prove that transactions coming from certain IP addresses are slower than others.

Note about the accessing the Transaction Log table

Because the Transaction Log table is very large, you should always exercise caution when querying it. For most customers, a 24-hour of time is the maximum span of time that should be queried on the Transaction Log table. Any more than that and the queries can become quite slow. However, if you have a specific filter on an indexed field you could query a larger period without trouble. For this reason, the modules that access the table (System Diagnostics > Transactions, System Diagnostics > Transactions (background), and System Diagnostics > Transactions (all users)) all have a default filter on Created On = Today and excluding any transactions initiated by the "guest" user. However, in some customer systems, even querying a 24-hour period might be too much for the system to handle in a reasonable amount of time. For that reason, the best practice is to first access the table by URL and use the sysparm_filter_only=true parameter to display only the list filter. From that point, you can specify a very limited query for only the information that you need. Try to specify the shortest time period required using a Between filter paired with some other restrictive filters such as Response time > 1000 or Created by = joe.employee.

NOTE: Seeing many transactions created by the "guest" user is perfectly normal behavior in ServiceNow. The "guest" user is just the user that the system attributes for transactions where the user is currently not authenticated, like if they access a public page or if they access a private page but are redirected to the login screen due to not being authenticated yet.

Steps to efficiently query for relevant log entries

1. Find out the User ID of the person who experienced the issue from the user table (sys_user).
   
   
2. Find out when they experienced it; down to the minute if possible.
   
   
3. Find out what that user was doing when the issue happened.
   
   
4. Log in to the instance as an admin user.
   
   
5. Go to <my_instance_name>/syslog_transaction_list.do?sysparm_filter_only=true.
   
   
6. Expand the graphical filter builder for the list and add the following filter to grab all transactions by that user around the reported time:
   [Processing start time] [between] [<some_time_before_event>] and [<some_time_after_event>]
   [Created by] [is] [<user ID of affected_user>]
   
   
7. Click Run.
   
   
8. From the list of transactions that comes back, see if the URLs or response times seem to match the description of the issue that was given by the user.

 

Also of interest might be KB0997495 - How to troubleshoot a slow transaction.

Definitions of the Fields of the Transaction Log table

If you haven't already done so, click the gear icon on the list to personalize the columns that are displayed in the list. The columns described in this section might be useful to you.

Server Metrics (listed alphabetically by field label)

• App Scope (app_scope): The parent scope from which the transaction was executed.
  
  
• Business Rule Time: (business_rule_time) The number of milliseconds spent executing Business Rules or Script Jobs. Script Jobs includes scheduled script executions and asynchronous Business Rules. This is inclusive of time spent downstream from the first Business Rule called. The timer starts once a Business Rule begins and stops only when that Business Rule is complete, including any time spent waiting on SQL to complete or any other Business Rules or processes that are triggered from the script of the top Business Rule. There are other ways that SQL can get triggered outside of Business Rules, so it is entirely possible that SQL Time may be listed as being greater than Business Rule time; however, you should keep in mind that whatever time spent running SQL was triggered by a Business Rule will be included in the calculation of Business Rule Time.
  
  
• Created: (sys_created_on) The moment the transaction was recorded. Note that transactions are recorded at the end of the transaction. Therefore, to determine the start time of a transaction (including scheduled jobs), you must subtract the Response time value from the Created time.
  
  
• Created By: (sys_created_by) The User ID (sys_user.user_name) of the user who performed the transaction. Most background/scheduled jobs are run by a special user called "system". Transactions initiated by a user's pre-authentication will be marked by a special system user called "guest".
  
  
• IP Address: (ip_address) The source IP address of the transaction inbound to ServiceNow.
  
  
• Network Time: (network_time) As of Zurich, this is the time it takes the server to write all the bytes of the response to the output stream - not the time it takes to transmit those bytes across the internet. This is not what most people expect from a measurement named Network Time. It is much lower than what most people would expect, usually in the range of 0 to 5 milliseconds. This metric is mostly not helpful.
  
  
• Processing start time (start_process_at) shows the time when a transaction was given a thread and actually began to be processed.
  
  
• Response Time: (response_time) The number of milliseconds spent by the server in fulfilling the transaction. Does not include server time spent prior to a redirect (HTTP 302). Does not include time spent on subsequent, partial page requests (i.e., AJAX) or serving up a resource (CSS, JavaScript, images, etc). Does include wait time from waiting for a semaphore or waiting for a previous transaction on the same session to complete. Therefore, this can be a confusing and inflated metric because some transactions may have 90% or more of their response time spent waiting for another transaction to complete.
  
  
• Semaphore wait time (semaphore_wait_time): Wait time in milliseconds caused by all semaphores being in use.
  
  
• Session: (session) The Java session ID of the user who was logged in. This ID is useful for identifying log messages output by this same user in the System Logs. For background jobs the Session ID will contain the name of the worker that is executing the job.
  
  
• Session wait time (session_wait_time): Wait time in milliseconds caused by the same user session initiating a second transaction before the first has completed.
  
  
• SQL Time: (sql_time) The number of milliseconds spent waiting for the request and response to the database. This can be artificially bloated in cases where a resource that is involved in handling the request/response to the database is overloaded (e.g., application server CPU, network bandwidth between app server and db server). One thing to note is that homepages employee multithreading and can execute multiple SQL statements simultaneously. SQL Time is the total of all SQL executed as part of a transaction on the main thread or child threads and therefore SQL time for home.do transactions is often greater than the total transaction processing time.
  
  
• System ID: (system_id) This field includes the name of the node upon which the transaction was executed.
  
  
• Table: (table) The table that was displayed, for example, incident, change_request.
  
  
• Total wait time (total_wait_time): Time in milliseconds that the transaction spent waiting before the server was able to process it.
  
  
• Transaction Pattern: (transaction_pattern) The unique hash code identifying an anonymized URL - this can be used to link a specific transaction in the logs with the Slow Transactions module (sys_transaction_pattern table).
  
  
• Transaction processing time (transaction_processing_time): Server response time, minus wait time. A good way to measure what transactions are actually using all the processing time.
  
  
• Type: (type) The type of transaction (such as form or list).
  
  
• URL: (url) The destination address from the inbound HTTP request. In the case of Scheduled Job transactions, this will be the prefix "JOB:" followed by the name of the job.
  
  
• User Agent: (user_agent) A user agent string is a unique identifier to identify the browser and operating system that initiated the transaction (see http://www.useragentstring.com/index.php).
  
  
• View: (view_id) The View (sys_ui_view table) that was used for this form/list.

Client Transaction Timings

Timings that track operations on the client-side (i.e. on the browser or mobile device). Not available for all transaction types. Not available on Safari. Generally, client timings are only available for the "Core UI" of ServiceNow, however, as of 2025 some of these metrics are being supported for Next Experience transactions like /api/now/graphql, /$uxapp, /api/now/v1/batch, /api/now/uxf/databroker/exec, and so forth.

• Client Transaction: (client_transaction) True if the transaction has successfully recorded client timings.
  
  
• Client Response Time: (client_response_time) The number of milliseconds between navigationStart and loadEventEnd. In other words, the total time, including server time, between when a page was requested and the HTML load event completed firing. This would include onLoad client scripts and any onChange scripts that fired as a result. In other words, this is inclusive of server time, browser time, javascript and any time spent on the HTTP request or HTTP response. This is the most inclusive timing metric and therefore should be bigger than other times. There are exceptions to this rule, like SQL Time, that can count cumulative time from multiple threads.
  
  
• Client Network Time: (client_network_time) Reflects a calculated value.
  
  
  • For the Core UI transaction types, the client_network_time calculation is the total "duration" as measured as follows:
    
        [End to end transaction duration] - [server time] - [browser render time] = client_network_time
    
    
    • You may notice slight inconsistencies with this formula for some transactions, but it is mostly accurate.
      
      
    • One item of note is that transactions that are directly preceded by an HTTP 302 redirect will reflect the transaction response time of the previous transaction in their client_network_time. This is the current behavior of the product and there is not a plan to change this behavior [as of Oct 30, 2018]. This is documented in PRB632265. This misattribution of server time as client network time is most commonly seen in transactions in the Core UI Service Catalog because all Service Catalog transactions use a 302 redirect. From the point you start to order an item until the point where you hit the order summary page, there is a first transaction that hits service_catalog.do processor, and then a second transaction redirected to the appropriate page.
      
      
    • For browsers that don't support the Performance Timing DOM object, client_network_time is determined by the difference between the point in time when the page started loading and when the page was requested, minus server time. This can result in bloated times since some time that is actually browser time is being recorded as network time. Almost all browsers support the API. See a list of supported browsers at https://developer.mozilla.org/en-US/docs/Web/API/Performance
      
      
  • As of 2025, client_network_time is being used to track response times for transactions related to the Next Experience UI, like Configurable Workspaces. The calculation is made as follows:
    
        [responseStart] - [fetchStart] - [syslog_transaction.response_time] = client_network_time
    
        For more information about troubleshooting Next Experience performance, see KB1640661 How to troubleshoot Slow Transactions or Page Load Issues in Next Experience Workspace and Portal Experiences.

Starting in Fuji, ServiceNow uses the window.performance object to handle calculations of most client timings. This object is a web standard that is supported by all modern browsers for a decade as of 2025. For more information about this window.performance, see the following resources:

 

The following image shows a quick reference of the timeline of the navigation timing web standard.