---
sourceDocument: Brazil ServiceNow AI Platform Administration
sourceDocumentLink: https://www.servicenow.com/docs/r/platform-administration

 Release :

    - brazil

ft:locale :

    - en-US

ft:publication_title :

    - Brazil ServiceNow AI Platform Administration

ft:clusterId :

    - platadm

bundleId :

    - platadm

workflow :

    - Platform


---

# Stats Tools

# Stats Tools {#ariaid-title1}

Release version: Brazil  
Updated September 10, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 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 Stats Tools

Stats Tools is a built-in ServiceNow feature designed to help evaluate system performance by recording statistics on key activities such as queries, scripts, and transactions.
It is activated by default and requires the admin role for activation or upgrades.
The tool captures detailed timing and execution data, enabling performance diagnostics and optimization.
Show full answer Show less  

## Key Features

* **Performance Modules:** Accessible under System Diagnostics \> Stats, including Slow Queries, Slow Scripts, and Slow Transactions modules, which provide insights into performance bottlenecks.
* **Activity Pattern Tables:** Uses tables (\[sysquerypattern\], \[sysscriptpattern\], \[systransactionpattern\]) to aggregate unique activities over time, storing timing metrics and execution details.
* **Cache and Persistence:** Activities are first recorded in a cache and later persisted to pattern tables. Flushing server caches clears any unpersisted data.
* **Filtering by Application Scope:** Logs can be filtered by application scope to focus on transactions originating from specific scopes, aiding debugging.
* **Execution Aggregation:** Each unique query, script, or transaction aggregates execution counts and metrics to provide overall performance trends.
* **Detailed Metrics:** Includes total and average execution times, server load times excluding waits, and other relevant timing statistics for each activity pattern.
* **Metadata for Debugging:** Stores example execution data such as URLs, script lines, table names, and query components to help identify and analyze performance issues.

## Characterization of Activity Types

* **Transactions:** Covers server-side and related client-side transactions, measuring total server load time. Identified by URLs, transaction types, processors, and form/list actions.
* **Scripts:** Includes scripts evaluated by GlideScopedEvaluator. Jelly scripts are identified by file path and line number; other scripts by table and sysid.
* **Queries:** Captures prepared statements executed by GlideDBI, including MongoDB queries and SQL-like statements with details on columns, clauses, and limits.

## Practical Benefits for ServiceNow Customers

By leveraging Stats Tools, ServiceNow customers can proactively monitor and diagnose performance issues related to database queries, scripting, and transactions. This enables targeted optimization efforts, improving system responsiveness and user experience. The ability to filter logs by application scope enhances troubleshooting efficiency, especially in complex environments with multiple scoped applications.  
To aid in performance evaluation, the Stats Tools records statistics for system
activities that affect performance such as the execution of queries, scripts, and
transactions.  
Note:  
The Stats Tools plugin is activated by default. It requires the admin role to activate or upgrade, and it requires the com.snc.jrobin.  
Stats Tools adds modules under System DiagnosticsStats, including Slow Queries, Slow Scripts, and Slow Transactions. Each module accesses a table of activity patterns \[sys_query_pattern\], \[sys_script_pattern\], \[sys_transaction_pattern\]. Each pattern table represents a collection of unique activities. Each collection is an aggregation of executions of that unique activity over all time. Each record provides basic timing analysis with example identifiable details of the activity.  
Note:  
To aid in debugging, you can filter most of these logs by application scope, limiting the transactions (for example, slow scripts or events) to only those transactions originating in specific scopes.

Activity patterns are immediately recorded to a cache and are later persisted to their pattern
table. If you flush server caches, then recorded activities that have not been persisted are
cleared. The following are examples of pattern records.

* Each time a query is executed that meets the recording and persistence threshold it is aggregated and stored as a query pattern record.
* Each time a particular business rule is executed it aggregates to a script pattern record.
* Each time a particular background job runs it aggregates into a unique transaction pattern record.
* Each click of the New button on the Incidents list counts as a list type transaction pattern with specific form action.

{#c_StatsToolsDiagnosticsPlugin__ul_s2r_dzt_jt}

## Metrics

Metrics include total and average times of interest per unique execution pattern over the
total execution count. Metrics are aggregated with each new instance of the unique activity and
persisted to the pattern record.

## Metadata

Example data from specific executions are included on each pattern to identify execution
details.

## Characterizations of each activity type

|-|-|
| Transactions | Any transaction type includes server-side and related client-side transactions. Metrics include Total server load time, which aggregates the total server-side time excluding semaphore and session wait times. It also aggregates relevant server transaction times that are found on the syslog_transaction table. Transaction types: * An HTTP Request transaction is identified by a URL, transaction type, processor, form/list action, URL query (filters), and related table name. * Any other transaction is identified by its transaction URL/page/name, transaction type, and processor or thread name. {#c_StatsToolsDiagnosticsPlugin__ul_byy_b15_jt} |
| Scripts | Any script activity type includes scripts evaluated by GlideScopedEvaluator. Script Types: * A Jelly Script is identified by the sys_jelly_file table, jelly file path, line number, and script that was executed. * Any other script is identified by the table and sys_id. {#c_StatsToolsDiagnosticsPlugin__ul_dfd_d15_jt} |
| Queries | Any query activity includes prepared statements executed by GlideDBI. Query Types: All queries are identified by MongoDB query or insert, update, or select statements, as well as other components of the statement like selected columns, where clause, unions, column sets, and limits. |
[Table 1.]

{#c_StatsToolsDiagnosticsPlugin__simpletable_yyk_115_jt}

*[\>]: and then