Monitoring ServiceNow Platform Performance: Combining Outside-In and Inside-Out Perspectives

agoldsch · 28m ago

Why Performance Monitoring Matters

The performance of your ServiceNow platform is crucial for user adoption and business value realization. When access is smooth, fast, and reliable, users are more likely to engage with the platform. Poor performance, on the other hand, leads to frustration, increased support tickets, slower task completion, and reduced usage — ultimately eroding the business benefits the platform is meant to deliver.

As ServiceNow platforms grow in complexity and scale, maintaining optimal performance becomes increasingly challenging. Continuously monitoring the operational performance of your instances is instrumental in identifying issues, ideally before they start impacting your users.

Combining Outside-In and Inside-Out Monitoring

Traditional monitoring approaches often focus exclusively on either user experience or system metrics, creating blind spots that lead to:

User complaints that don’t correlate with system health indicators
Performance optimizations that don’t improve actual user experience
Difficulty prioritizing improvement efforts
Reactive rather than proactive performance management

The dual-perspective approach presented in this article addresses these gaps by combining two complementary views:

Outside-in view: Measures what users actually experience when interacting with the platform
Inside-out view: Examines underlying platform components and their impact on user experience

Graphic 1 - Performance monitoring.png

By integrating both perspectives, you can identify performance issues more accurately and prioritize optimization efforts based on real user impact.

The Outside-In View: User Experience First

What Is the Outside-In Perspective?

The outside-in perspective focuses on the platform from the user’s point of view. It answers the fundamental question:

How fast and responsive does the platform feel to actual users?

This view captures the end-to-end experience, including server-side processing, network latency, client-side processing, and other factors that contribute to perceived performance.

Key principle: If users perceive the platform as slow, it is slow — regardless of what backend metrics indicate.

Overview of ServiceNow User Interfaces

Your ServiceNow users interact with the platform through multiple interfaces. This article focuses on monitoring the performance of the most commonly used web-based UIs:

Classic Environment: The traditional interface for agents and fulfillers using lists, forms, and dashboards. Originally known as UI16 or Classic UI, it now runs within the Next Experience app shell alongside modern workspaces.
Configurable Workspaces: The modern interface for agents and fulfillers using role-based, configurable layouts that consolidate relevant information and tools into a single, focused work area.
Portals (Employee Center, Service Portal): The primary interface for end users (employees, customers) to raise requests, approve items, search for information, and work on tasks.
Other interfaces (not covered in detail): Virtual Agent (conversational interface), Mobile apps (Now Mobile App, Mobile Agent App), Email, APIs

Identifying Top Transactions

Given the vast number of transactions users perform on the ServiceNow platform, it is advisable to first define which transactions are most critical to monitor and improve on an ongoing basis.

Criteria for identifying top transactions:

Highest execution count (e.g., transactions per minute)
Highest average execution time
Highest total execution time
Highest volume of user complaints

Where to find transaction data:

For Classic Environment and Portals, review the transaction log and the slow transaction log:
System Logs > Transactions [syslog_transaction.list]
System Diagnostics > Stats > Slow Transactions [sys_transaction_pattern.list]
ServiceNow Impact customers can use Instance Observer’s Top Transactions view to analyze transactions based on volume and execution times.

For Configurable Workspaces, review the client interactions table:
System Logs > Client Interactions [sys_client_interaction.list]

Recommended starting point: Focus on the top five transactions per category (Classic Environment, Configurable Workspaces, Portals).

Key Metrics and Implementation Considerations

After identifying the most impactful transactions, measure how users perceive their performance. Choose metrics that directly reflect or closely align with user satisfaction.

Because the technical foundations differ, not all of the approaches described below apply equally across Classic Environment, Configurable Workspaces, and Portals.

Transaction Log

Applies to: Classic Environment, Portals
Table: syslog_transaction

The transaction log records all browser activity for an instance. With the Client Transaction Timings plugin installed, additional drill-down options become available.

Key data fields:

Field	Description
Created	Date and time of the transaction
Created by	User who created this activity
Type	Type of transaction (e.g., List, Form, REST)
Table	Table involved (e.g., incident, change_request)
URL	Application or module accessed
Client Interaction Id	ID of corresponding record in client interactions table
Transaction pattern	Reference to record in slow transactions log (sys_transaction_pattern)
Client response time	Total client time: (load_completion_time) – (start_time), incl. server time
Response time	Server time in milliseconds
SQL time	Time spent in SQL database (ms)
Client network time	Time spent in network transmission (ms)
Browser time	Time spent by the browser (ms)
Business rule time	Time spent executing business rules (ms)
Client script time	Time spent executing client scripts (ms)
UI policy time	Time spent executing UI policies (ms)
Sempahore wait time	Total time spent waiting for an available semaphore (ms)
Session wait time	Total time spend waiting for the session synchronizer (ms)
Total wait time	Total time waited before starting this transaction (ms)

Use cases:

Detailed analysis and troubleshooting of individual transactions
Continuous monitoring, time-series reporting, trending, and alerting (requires custom implementation)

Implementation considerations:

Aggregating raw data meaningfully requires considerable effort
Limited retention times must be factored into solution design
Integration with external data warehouses or BI tools may be needed

Limitations:

You only see transactions that reach the ServiceNow instance (not a true client-side view)

Slow Transactions Log

Applies to: Classic Environment, Portals
Table: sys_transaction_pattern

The slow transactions log provides aggregated data for transactions that have exceeded the slow transaction thresholds.

Key data fields:

Field	Description
Origin application	Application scope the transaction originated in
Example type	Example transaction type executed
Example URL	Example processor for an individual transaction
Execution count	Number of similar occurrences aggregated
Average execution time (ms)	Average duration per transaction occurrence
Total execution time	Total sum of execution times for aggregated occurrences
Average client time (ms)	Average client-side duration per occurrence
Total client time (ms)	Total sum of client-side execution times

Use cases:

Identify transactions that are both slow and frequently executed
Prioritize optimization efforts based on combined impact
Less suitable for continuous monitoring or time-series reporting (see limitations)

Implementation considerations:

Aggregating raw data meaningfully requires considerable effort
Limited retention times must be factored into solution design
Integration with external data warehouses or BI tools may be needed

Limitations:

Specific transactions cannot always be reliably identified based on example type and URL
Classification as “slow” can vary over time
You only see transactions that reach the ServiceNow instance (not a true client-side view)

Client Interactions Log

Applies to: Configurable Workspaces
Table: sys_client_interaction

With the growing adoption of Configurable Workspaces, understanding Next Experience UI performance is critical. The client interactions table provides detailed performance data for Next Experience pages.

Key data fields:

Field	Description
Created	Date and time the record was created
Application	Application the URL belongs to
Referrer	URL being accessed
UFX screen route	Route used to load the page
Type	Interaction type: PAGE_LOAD (full page load), NAVIGATION (routed within SPA), IN-PAGE (interaction within page)
Total UI time	Time (ms) for the page to load
Content download time	Time (ms) for content to transfer from server to client
Interruption	Type of page load interruption; displays “none” if no interruption occurred
Name	Contextual information for in-page interactions
Data	Contextual information for in-page interactions

Use cases:

Detailed analysis and troubleshooting of individual transactions
Continuous monitoring, time-series reporting, trending, and alerting (requires custom implementation)

Implementation considerations:

Aggregating raw data meaningfully requires considerable effort
Limited retention times must be factored into solution design
Integration with external data warehouses or BI tools may be needed

Limitations:

You only see transactions that reach the ServiceNow instance (not a true client-side view)

User Experience Analytics (UXA) — Recommended

Applies to: Classic Environment, Portals, Configurable Workspaces

The User Experience Analytics application provides insights into how users interact with the instance, including transaction performance.

Key capabilities and use cases:

Usage monitoring: Visualize metrics and interactions through comprehensive dashboards
Performance indicators: Monitor KPIs for user adoption
User journeys: Design better user journeys based on interaction insights
Operational optimization: Optimize operational KPIs to enhance user experience
Retention and cohort analysis: Understand user retention and behavior patterns
Conversion funnels: Analyze conversion rates and identify areas needing attention
Navigation paths: Assess user navigation to enhance the overall journey
Session and event analysis: Drill down into individual sessions for detailed insights

Implementation considerations:

Out-of-the-box solution requiring minimal effort for implementation
Important: Tracking depends on configured tracking consent policies. Users can opt in or opt out of advanced tracking at any time. For additional details, please visit User privacy, tracking, and user consent management in User Experience Analytics.

Benefits:

Translates technical data into actionable insights, presented in an intuitive, non-technical user interface
Provides a holistic, user-centric view beyond performance, revealing friction points and journey drop-offs
Handles the heavy lifting required to analyze and visualize raw transaction data — development of a custom solution is not needed
Natively supports all user interfaces, including Configurable Workspaces

Real User Monitoring (Using Third-Party Tools) — Recommended

Applies to: Classic Environment, Portals

Real User Monitoring (RUM) collects data directly from the browsers and devices of actual users as they interact with a website or application. Organizations with an enterprise RUM solution (e.g., Dynatrace, New Relic) can leverage it to monitor ServiceNow user transaction performance.

Example metrics:

Time to visually complete
Network / server / frontend breakdown based on W3C navigation timings
Total actions per minute
Errors per minute
Apdex rating (Satisfied, Tolerating, Frustrated)
Geographic distribution
Device types, browser and OS versions
Connection speed

Implementation Considerations:

Typically requires injecting a JavaScript snippet into ServiceNow pages
Can be implemented with low customization effort for Classic Environment and Portals (e.g., using a global UI script)
Not recommended for Configurable Workspaces as it would require major UI component-level customizations, resulting in poor upgradeability

Benefits:

Full visibility into what users actually experience, including detailed front-end performance and client-side errors — not limited to what reaches the ServiceNow instance
Detailed performance breakdown (frontend, network, backend)
Clear user journeys and session-level context
Rich environment metadata (device, browser, geo, network)
Leverages integration with a broader observability stack, including alerting and incident reporting

User Satisfaction Surveys — Recommended

Applies to: All user interfaces

ServiceNow provides built-in Assessments and Surveys functionality to collect user feedback on service quality and measure customer satisfaction (CSAT).

Even with detailed performance measurements in place, satisfaction surveys provide valuable perspective by capturing non-quantifiable aspects of customer satisfaction and gauging sentiment across the user community.

Getting Started with Outside-In Monitoring

Follow these steps to implement outside-in performance monitoring:

Identify relevant user interfaces for your user community (Classic Environment, Portals, Configurable Workspaces).
Identify the top five user transactions per interface based on execution count, execution time, and user complaints.
Evaluate monitoring tools:
- ServiceNow User Experience Analytics
- Existing third-party RUM solutions (e.g., Dynatrace)
- Custom solutions using ServiceNow analytics or external data warehouse/BI integrations
Define clear responsibilities for outside-in performance monitoring (e.g., ServiceNow operations team).
Establish baselines for user transaction response times.
Identify and document acceptable performance thresholds, considering user expectations and baseline response times.
Set up alerts for threshold violations and define clear responsibilities for acting on alerts.
Review and adjust baselines and alerting thresholds regularly.
Plan and conduct regular user satisfaction surveys focused on performance as perceived by the user community.

The Inside-Out View: Know Your Instance

What Is the Inside-Out Perspective?

The inside-out perspective examines the platform’s internal components, processes, and resource utilization. It answers the question:

What is the platform doing, and how efficiently is it doing it?

This view helps identify bottlenecks, inefficiencies, and resource constraints that may impact user experience.

Metrics Framework for Inside-Out Monitoring

For inside-out monitoring, the approach presented in this article is based on Instance Observer, a powerful observability and performance monitoring tool included in ServiceNow Impact that provides near real-time insights and historical data on instance health and performance.

Instance Observer provides a large set of performance metrics. To keep things manageable, we concentrate on the most important ones and organize them within a three-tier framework:

Transaction Tier: metrics related to performance of transaction processing
Application Tier: metrics related to application node health and performance
Database Tier: metrics related to database health and performance

Graphic 2 - Metrics framework.png

Note: The User Transactions box in this framework corresponds to the outside-in perspective covered earlier. For inside-out monitoring, however, instead of examining how transactions perform for users, we focus on how well the instance can handle the combined volume of user transactions.

Transaction Tier Metrics

User Transactions

Instance Observer includes instance-wide metrics for User Transaction Count and Average Server Response Time, but these are of limited use for reliable performance monitoring because they consider only classic, whole-page transaction types and exclude AJAX, Angular, REST, Scheduler, Agent Workspace, and SOAP transactions.

Recommended metrics:

Metric	Description
Semaphore Default Mean	Average number of default semaphores in use over a one-minute period, reflecting the number of the most significant end-user transactions being processed simultaneously. Out of the box, the default semaphore pool has 16 threads. Sustained usage of 10 or more on a single node may indicate a severe performance issue.
Semaphore Default Qdepth	Number of transactions currently in the default semaphore pool request queue of an application node, awaiting processing. Small numbers of queued requests are common during normal operation. By default, the queue can hold a maximum of 150 transactions. Sustained spikes may indicate performance issues processing user transactions.

Integrations Transactions

Integrations transactions do not go through the default semaphore pool but are handled by a more specific integrations semaphore pool (API_INT).

Recommended metrics:

Metric	Description
Integrations Semaphore in Use	Number of API_INT semaphores in use to execute a transaction on an application node at a given point in time. For best response time, each application node should have some free API_INT semaphores available at all times.
Integrations Semaphore Qdepth	Number of transactions currently in the API_INT semaphore pool request queue of an application node, awaiting processing. Small numbers are common during normal operation. By default, the queue can hold a maximum of 50 transactions. Sustained spikes may indicate performance issues related to integration transactions.

Scheduled Jobs

Scheduled jobs include scheduled reports, script executions, data imports, audits, timers, and asynchronous business rules (e.g., discovery sensors).

Recommended metrics:

Metric	Description
Scheduler Queue Length	Number of claimed scheduled jobs in each application node’s scheduler queue (excluding jobs currently executing). It is common to see a significant scheduler queue length at any point in time. However, if a single node shows a high queue length for a sustained period (more than 60 minutes) and scheduler age is increasing, that node may have issues processing scheduled jobs.
Scheduler Mean Queue Age	Average age of all unprocessed jobs in an application node’s scheduler queue. A large scheduler mean queue age can indicate that an application node is struggling to process claimed jobs in a timely manner.

Application Tier Metrics

Several CPU- and memory-related metrics are available for monitoring application-tier components (UI and worker nodes).

Recommended metrics:

Metric	Description
Node CPU Time	Absolute value in milliseconds of CPU utilization per node at a given data point in history.
Node Memory Max	In-use memory max per node at a given point in time. This value normally ranges between 1000 MB and 2048 MB. If maximum memory reaches 95% of available memory at least 5 times in the past 15 minutes, the node’s memory is almost full.
Node Garbage Collection Time	Percentage of time spent doing Java garbage collection to ensure sufficient memory remains available. Excessive garbage collection can cause severe performance issues.

Database Tier Metrics

Performance metrics for the database tier are available at both aggregated and granular levels, allowing analysis of response times on average and per individual database transaction type (delete, insert, select, update).

Recommended metrics:

Metric	Description
SQL Response Time	Reported mean of database response time. Measured at the application layer with a timer that starts when a query is sent to the database and finishes when the response is received. Includes time spent on the network between the application server and the database server. Important: Resource contention on the application layer may cause misleading increases in SQL response time. Additionally, SQL response time increases do not necessarily correlate with service-impacting issues.
History List Length	The database tries to respond to SQL queries as quickly as possible, but some queries take longer when the data set is large and requires analytical processing. If the data set being queried is also updated frequently, concurrent select-and-update operations on the same data set negatively affect database query performance. In ServiceNow database technology, this is tracked with History List Length (the length of the linked list that keeps old versions of rows as they are modified). History List Length impacts overall instance response time for any workload if it occurs during peak business hours.

About the ServiceNow HealthScan Performance Score

ServiceNow HealthScan is a diagnostic tool that assesses the current health of your ServiceNow instance, identifies potential issues, and facilitates quick corrective actions. Using best-practice definitions, it provides insight across five categories: Security, Upgradability, Performance, Manageability, and Usability.

Important distinction: HealthScan helps reduce technical debt and optimize performance by preventing common implementation missteps, but it does not provide a view of the current operational performance of your ServiceNow platform.

A below-average HealthScan performance score does not necessarily mean poor operational performance if the underlying infrastructure can handle the load.
An above-average HealthScan performance score does not guarantee good operational performance if the underlying infrastructure is not properly sized and implemented.

Conclusion: The HealthScan performance score is not appropriate for continuous monitoring of outside-in and inside-out operational performance of your ServiceNow platform.

Getting Started with Inside-Out Monitoring

Follow these steps to implement inside-out performance monitoring:

Obtain Instance Observer access (ServiceNow Impact customers: work with your Customer Success Manager or Support Account Manager).
Familiarize yourself with Instance Observer functionality and available metrics.
Select the metrics you will monitor using the guidance provided in this chapter.
Define clear responsibilities for inside-out performance monitoring (e.g., ServiceNow operations team).
Establish baselines for the selected metrics.
Identify and document acceptable thresholds for the metrics in scope.
Set up Instance Observer alerts for threshold violations and define clear responsibilities for acting on alerts.
Review and adjust baselines and alerting thresholds regularly.
Stay aligned with your Support Account Manager (e.g., via regular Performance Management Reviews).
If using Preventive Care, share your observations and findings with the Preventive Care team for consideration in the current or upcoming improvement cycle.

Accelerated Performance Monitoring with ServiceNow Impact

NOTE: ServiceNow Impact Package Descriptions apply.

Impact Squad

Your Platform Architect (PA) provides the technical leadership needed to set up and maintain a high‑performing, resilient ServiceNow platform. In addition to guiding your performance monitoring strategy, the PA helps establish an effective Technical Governance framework that drives adherence to best practices and maximizes the use of out‑of‑the‑box functionality.

Additional members of the Impact Squad — including the Customer Success Executive (CSE), Customer Success Manager (CSM), and Support Account Manager (SAM) — work closely with you and your PA to ensure alignment with business objectives, leverage Impact Accelerators as needed, and troubleshoot issues as they occur.

Impact Accelerators

Impact Accelerators are fixed-scope offerings with experts behind each option to provide value where you need it. They provide recommendations and insights in a short time frame, so you get value quickly.

Three categories of Impact Accelerators are available:

Architecture Accelerators provide a foundational understanding of business outcome maturity with targeted recommendations on what to tackle next to unlock further value from the platform.
Strategy Accelerators go deeper on organizational and governance best practices with the ServiceNow platform and upskill your team to maintain business performance and drive success.
Technical Accelerators accelerate usage and adoption of specific platform and product capabilities via applied demonstrations, personalized coaching, and best practices. The Accelerators are delivered by the Impact Squad and technical consultants, as necessary.

Consider the following accelerators to speed up your performance monitoring initiative:

Access to Experts connects Impact customers to ServiceNow subject matter experts via personalized virtual coaching sessions, providing prescriptive and actionable guidance on ServiceNow product topics.
Introduction to Instance Observer provides guidance on understanding and monitoring performance using Instance Observer.
Health Assessment provides insight into your ServiceNow instance health.
Jumpstart Your Database Management provides a comprehensive overview and practical demonstration of effective database management to help efficiently manage your database footprint and alleviate performance issues.
Jumpstart Your Platform Analytics and TuneUp Your Platform Analytics provide an applied demonstration of the capabilities of advanced Platform Analytics configuration, including Performance Analytics, Workspaces, and User Experience Analytics.

Instance Observer

Instance Observer (IO), as already covered in the inside-out monitoring chapter, is a powerful observability and performance monitoring tool that provides near real-time insights and historical data on instance health and performance.

Instance Observer key capabilities include:

24/7 monitoring: Instance performance monitoring provides awareness of issues within an instance before end users are impacted.
24/7 alerting: Set up custom alerts to notify you when specific thresholds are crossed, so you can act before an issue becomes critical.
Multi-instance availability: Proactively visualize performance telemetry across instances.
Triage: Actionable point-in-time instance metadata providing additional context to instance performance and accelerating troubleshooting.
Off-instance application: Access instance performance telemetry off instance. When an issue does arise, organizations can access actionable data independent of instance availability.
Reporting: Visualize instance performance telemetry over time and quickly generate reports to share with your business stakeholders.
Analytics: Compare metrics over time to see how performance is trending in general or to assess the before-and-after impact of certain changes.

Recommended reading: Best Practices for Instance Performance Monitoring with Instance Observer

Preventive Care

Preventive Care is a premium, engineer-led diagnostic of instance performance executed on a regular cadence and available as an add-on package to all ServiceNow Impact customers. It helps maintain optimal performance of large, strategic ServiceNow implementations and includes:

Holistic performance review: ServiceNow performance experts review a broad range of metrics covering all aspects of instance operation.
Identification of issues: Uncovers areas of resource contention, performance degradation, or misconfiguration that impact end-user experience or instance stability.
Guided implementation: Performance experts provide hands-on assistance with planning, implementing, and validating recommended improvements and fixes.

Recommended reading: Preventive Care - What Do you Get, and How Can it Help You?

Conclusion

Effective ServiceNow platform performance monitoring requires a holistic approach that combines outside-in user experience monitoring with inside-out platform health analysis.

The dual-perspective approach presented in this article provides a framework and foundation for building a mature, proactive performance management practice. Start by implementing monitoring for both perspectives, establishing baselines for your most critical user journeys, and taking action based on identified performance degradations.

Remember: Performance is not a project — it’s a practice.

Commit to ongoing measurement, analysis, and optimization to ensure your ServiceNow platform delivers exceptional user experience at scale.