---
sourceDocument: Australia Impact
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/impact

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia Impact

ft:clusterId :

    - ipact

bundleId :

    - ipact


---

# Transaction or response metrics

# Transaction or response metrics {#ariaid-title1}

* Release version: Australia
* 
* Updated May 13, 2026
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 minutes to read

Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of Transaction or response metrics

This information explains key performance metrics for classic UI transactions within the ServiceNow AI Platform®.
These metrics help you understand transaction volumes, server response times, and the distribution of response time components such as server, network, and browser times.
They provide insights into core business hours performance and help identify potential performance issues.
Show full answer Show less  

## Key Metrics Explained

* **User Transaction Count (sum):** Represents the total number of classic UI transactions (UITYPE) across the instance, excluding AJAX, Angular, REST, Scheduler, Agent Workspace, and other modern transaction types. It primarily covers whole-page table-based form/list transactions. This metric is useful to gauge transaction volume during core business hours and to detect significant changes that might signal performance issues. However, it should be used only as a secondary indicator and not for direct troubleshooting.
* **Average Server Response Time (weighted average):** Measures the average execution time of UITYPE transactions on the server side, excluding semaphore wait times, session sync wait times, network latency, and client-side processing. Server response times typically fluctuate with business hours and transaction types, and longer response times during off-hours may be influenced by administrative activities. This metric should be interpreted cautiously, focusing on extreme deviations or correlation with other indicators rather than fixed thresholds.
* **Stacked Time Components:** Provides a breakdown of total transaction response time into three parts:
  * **Server Time:** Time spent by the server processing the transaction, excluding redirects, AJAX calls, resource serving, and wait times for semaphores or previous session transactions. This metric can be inflated if significant waiting occurs.
  * **Network Time:** Time taken by the server to write the request bytes to the output stream, not the actual network transmission time. This is typically much lower than expected.
  * **Browser Time:** Time spent by the browser rendering the request and response, usually less than server time but important to identify client-side performance bottlenecks.

## Practical Guidance for Customers

* High **server response time** suggests reviewing server-side components such as business rules, ACLs, SQL queries, semaphore waits, and session waits.
* High **network time** indicates the need to assess transaction data volume and optimize data streaming.
* High **browser time** points to reviewing client-side scripts and components for performance improvements.
* Use these metrics as part of a holistic approach; they provide a partial view of end-user performance and should be supplemented with other system performance measurements.  
The metrics provide a performance snapshot of classic UI transactions within the ServiceNow AI Platform®.

## User transaction count (sum) {#io-core-performance-metrics__section_okm_1qy_fjc}

Transaction count is the instance-wide sum of all UI transactions of a certain type known as UI_TYPE, which is a classification used only in ServiceNow proprietary code.

UI_TYPE excludes all AJAX, Angular, REST (including all ServicePortal and /api/now/ui/), Scheduler, Agent Workspace, SOAP etc. Essentially, it can be considered to cover only classic, whole page transaction
types for example, table based form/list transactions excluding List V3, home pages, UI pages.

This is useful to understand core business hours. Potentially useful as a secondary identifier of extreme performance issues if the number rapidly changes in minutes and stays that way for at least 10 minutes either up or down.  
Note:  
This indicator is only a secondary indicator, which can be used to understand the context where it is used, and cannot be directly used for troubleshooting.

## Average server response time (weighted average) {#io-core-performance-metrics__section_rmv_4wy_fjc}

Server response time in this context is the average/mean execution time for UI_TYPE transactions. See Transaction Count (sum) for limitations of this classification.  
In addition to these limitations, Server Response time also does NOT include:

* Time spent on waiting for a semaphore (if all semaphores are used by other users).
* Time spent waiting for session sync (if current user already has an active transaction).
* Time spent on the network back and forth to ServiceNow.
* Time spent on the client-side by the browser or mobile device.
{#io-core-performance-metrics__ul_o5y_3d3_hjc}

Server response time commonly fluctuates up and down in relation to core business hours due to the type of operations that tend to occur at any given time. Thus, it is very common that server response time appears more volatile
during nights and weekends because administrators are running long reports or administrative transactions that typically take longer to execute. This, combined with the fact that fewer overall transactions are occurring, means a few
slow transactions will have greater impact on the average.

When considering long-term trends, like Week over week comparisons for example, one should consider that such changes may simply reflect usage pattern changes, such as users doing more or less of certain types of transactions that
are typically faster or slower. Because each transaction type has different functional requirements, there is no arbitrary threshold for what constitutes a slow transaction and thus no threshold should be
applied to this metric. Instead of looking at long-term trends or short spikes outside core business hours, attention should be placed on extreme deviations from the norm or where this metric coincides with another performance
indicator.

Since this metric is limited to the response time of UI_TYPE transactions (see definition under Transaction Count (sum)), it may be a very incomplete picture of your end user's performance. Other methods of
measuring should be considered for aspects of total system performance.

## Stacked time: Server response time, Network time (network time, both from and to the user) and browser time {#io-core-performance-metrics__section_o4q_y2j_hjc}

Server, network, and browser response times are three key metrics in the life cycle of a transaction. Average Stacked time of a transaction provides an response time from three metrics in a pile of objects.

Server Time
:   The number of milliseconds spent by the server in fulfilling the transaction. It does not include:

    * server time spent prior to a redirect (HTTP 302)
    * time spent on subsequent, partial page requests (that is, AJAX) or serving up a resource (CSS, JavaScript, images, etc)
    * wait time from waiting for a semaphore or waiting for a previous transaction on the same session to complete

    {#io-core-performance-metrics__ul_hhc_kfj_hjc}

    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.

Network Time
:   It is the time it takes the server to write all the bytes of the request to the output stream - not the time it takes to transmit those bytes across the internet. This is not what most people expect from this measurement. It
    is much lower than what most people would expect.

Browser Time
:   It is the time taken by the browser during the transaction. It includes the request and response rendering time at the browser.

It gives a perspective of what is the biggest contributor for the total response time for a transaction. Usually, Server time is high compared to Network and Browser.  
Note:  
Review the following if:

* The server response time is high, then server side components must be reviewed further like business rule, ACL, SQL, Semaphore wait, Session wait time, and others.
* The network time is high, then transaction components and how much data is being streamed must be reviewed. Recommendation is to keep lightweight transactions with optimal data stream.
* The browser time is high, then client side scripts/components must be reviewed.
{#io-core-performance-metrics__ul_pzp_dhj_hjc}
**Related reference**   

* [Anomaly insights](https://servicenow-prod.fluidtopics.net/4_QeeoMptTF3e9qrg4XWwg "The reference topic gives additional information for anomaly charts.")
* [Feature availability based on package](https://servicenow-prod.fluidtopics.net/P9qjLGc3vCF_cOO3tzGPpA "The table outlines the access permissions for Performance Analytics features across production and sub production instances.")
* [Auriga Intelligent Alert report](https://servicenow-prod.fluidtopics.net/nQSJ7KPMZhRA30JC0WUapA "Auriga Intelligent Alert is an advanced multivariate machine learning (ML) model that learns from historical issues on your instance to provide real-time insight. Auriga monitors your performance metrics to deliver notifications of noteworthy events or deviations from anticipated data patterns.")
* [Database performance metrics](https://servicenow-prod.fluidtopics.net/BR2AN_h8wOEd8ZtqZdLf4A "The metrics provide the database performance snapshot within the ServiceNow AI Platform.")
* [Semaphores performance metrics](https://servicenow-prod.fluidtopics.net/Kk9mReT78mDBECtqFl7MWQ "The metrics provide the key performance indicators calculated at the instance level for the selected duration.")
* [Event queues performance metrics](https://servicenow-prod.fluidtopics.net/gJEASVHBrJdFQHIBS8345w "The metrics provide the event performance snapshot within the ServiceNow AI Platform.")
* [ECC Queue performance metrics](https://servicenow-prod.fluidtopics.net/RGxMtNOGgtVY6Q5itGNFaQ "The metrics provide the ECC Queue performance snapshot within the ServiceNow AI Platform.")
* [Email performance metrics](https://servicenow-prod.fluidtopics.net/bogAIEvZQM6EVgHuNANWkw "The metrics provide the Email performance snapshot within the ServiceNow AI Platform.")
* [Scheduler performance metrics](https://servicenow-prod.fluidtopics.net/mUgSGAMhziXWPxkMp4ZZJQ "The metrics provide the Schedulers performance snapshot within the ServiceNow AI Platform.")
* [Job details performance metrics](https://servicenow-prod.fluidtopics.net/zU5pCERdUDwYINhrEtEmVw "The metrics provide the job details performance snapshot within the ServiceNow AI Platform.")
* [Node health performance metrics](https://servicenow-prod.fluidtopics.net/Ym_5QZb7HaUEXusPO0FNVA "The metrics provide the node health performance snapshot within the ServiceNow AI Platform.")
* [Host health performance metrics](https://servicenow-prod.fluidtopics.net/BPg~fi7mWtO2QDvoJtmlbw "The metrics provide the host health performance snapshot within the ServiceNow AI Platform.")
* [Standby replication Lag](https://servicenow-prod.fluidtopics.net/~bnGXSPhIInh_QygPmu8lA "A read replica is a copy of the primary DB that reflects changes to the primary in almost real time, in normal circumstances. The lag represents the database server of the instance that is behind in seconds.")
* [Pool Replication Lag](https://servicenow-prod.fluidtopics.net/GZt7jzZ4mbs0axGHLTG75w "Pool replication lag is the number of seconds that a Standby database or a read replica database lags behind the primary database.")
* [Chat details performance metrics](https://servicenow-prod.fluidtopics.net/3ITlZgnjjx7hFU0jPdggHA "For the operations team to get the insights of current load across main components of AWA channel infrastructure like queues and agents, and to monitor load during events of chat spikes.")
* [Cluster details performance metrics](https://servicenow-prod.fluidtopics.net/gCpPJvTx4G~JcYX9~VAIVA "The metrics provide the cluster details and Encryption status snapshot within the ServiceNow AI Platform.")
* [Load balancer performance metrics](https://servicenow-prod.fluidtopics.net/U6~7lb0jujHirGTJlHHmZA "The metrics provide the load balancer performance snapshot within the ServiceNow AI Platform.")
* [User information metrics](https://servicenow-prod.fluidtopics.net/tzinVKez9tWy7F1KJoK7mg "The metrics provide the user information performance snapshot within the ServiceNow AI Platform.")
* [Instance Data Replication](https://servicenow-prod.fluidtopics.net/ScxZA~8x58vIrm57FTmurg "The Instance Data Replication (IDR) copies data updates from one instance, called the producer instance, to one or more other instances called the consumer instances.")