Skip to page contentSkip to chat
ServiceNow support
    • Community
      Ask questions, give advice, and connect with fellow ServiceNow professionals.
      Developer
      Build, test, and deploy applications
      Documentation
      Find detailed information about ServiceNow products, apps, features, and releases.
      Impact
      Accelerate ROI and amplify your expertise.
      Learning
      Build skills with instructor-led and online training.
      Partner
      Grow your business with promotions, news, and marketing tools
      ServiceNow
      Learn about ServiceNow products & solutions.
      Store
      Download certified apps and integrations that complement ServiceNow.
      Support
      Manage your instances, access self-help, and get technical support.
Analyze performance issues on Service Portal - Support and Troubleshooting
  • >
  • Knowledge Base
  • >
  • Support and Troubleshooting (Knowledge Base)
  • >
  • Analyze performance issues on Service Portal
KB0852502

Analyze performance issues on Service Portal


8297 Views Last updated : May 28, 2025 public Copy Permalink English (Original)
  • English (Original)
  • Japanese
KB Summary by Now Assist

Summary

Certain pages on Service Portal load very slowly, either when navigating to them or accessing them directly. This is commonly because one or a few widgets are taking most of the time to load. This article describes how to identify these scenarios.

Release

Applicable to all releases

Instructions

1. Determine which page is loading slowly. You can find this by following the Steps to Reproduce the issue, otherwise, load the page and look for the value present in the URL for id param (for example /sp?id=list)

2. Once identified, find out how much time it is taking for the page to load. You can check this on the browser dev tool's Network tab. This will tell how much time is taken on what aspect. 

In the following screenshot from a use case, notice the total time taken is 5.43 seconds, which is mostly waiting time of around 4 seconds.

Use case example showing waiting time

If the waiting time is taking the most of the time, this means that the response from the server takes longer.

3. Once it is determined that server time is taking more time, see which server functionality is responsible. There could three scenarios:

  • Slow running ACL
  • Slow running business rules
  • Slow running SQL queries.

4. To find out which of these are consuming the most time, go to System Diagnostics > Session Debug > Debug Log. 

5. After enabling the debug log, reproduce the issue and try to get the logs on the jsdebugger window or on a ui_page.do. If this transaction has taken more time, a log similar to the following will appear. The key word is EXCESSIVE. 

log05:15:20 AM.771 EXCESSIVE *** End #2298398 /api/now/sp/page, user: admin, total time: 0:00:06.484, processing time: 0:00:06.484, SQL time: 0:00:05.209 (count: 887), business rule: 0:00:00.001 (count: 6), ACL time: 0:00:00.001, Cache build time: 0:00:00.007, source: 103.23.66.61 , type:rest, method:GET, api_name:now/sp, resource:now/sp/page, version:Default, user_id:admin, response_status:200

This log shows which component has taken the most time. For this use case, the total time was around 6 seconds. This was distributed as SQL time= 5s, Business Rule= 1ms and ACL= 1 ms. This means that SQL queries are taking the most time. 
 
6. Once the component is known, look for that transaction's specific function. Remember to note the request URL that initiated this transaction. In this use case, it is an API call, /api/now/sp/page, which can be seen in the network logs.
 
7. Enable the session debug of that component. In this case, enable Debug SQL (detailed). Enabling the detailed log shows the trace of the queries and provides the sys_id of the widget that caused the slowdown. 
 
8. As the SQL debug is enabled, reproduce the issue, and then reload the ui_page.do to get the new logs.
 
9. Search with the API name and look for the transaction name under Queries, as shown in the following screenshot. This gives an explanation of how much time is taken by all the queries, per-transaction basis, and which query took what percentage of the time. 
 
 
Query to identify slow transactions
 
10. Once the query taking the most time is discovered (the product default view shows the long-running one at the top), search for the query in the logs, as shown in the following image. Copy the end part of the query to search, as the selection fields are usually hidden in the SQL statements. This returns the exact SQL entry logs, and the SQL log can be expanded to see which widget is causing the delays.
 
 
 
Log query search example
 
 
11. Analyze the widget, and then modify the query based on that analysis. 
 
 
This example shows the slowness is caused on Query. If it was caused by either Business Rule Or ACL, enable the respective session debug. This identifies which transactions takes the most time. Those can then be investigated and solved accordingly.
 
 

Related Links

  • Script Debugger and Session Log
  • Session Debug

The world works with ServiceNow.

Sign in for more! There's more content available only to authenticated users Sign in for more!
Did this KB article help you?
Did this KB article help you?

How would you rate your Now Support digital experience?

*

Very unsatisfied

Unsatisfied

Neutral

Satisfied

Very satisfied

Very unsatisfied

Unsatisfied

Neutral

Satisfied

Very satisfied

What can we improve? Please select all that apply.

What are we doing well? Please select all that apply.

Tell us more

*

Do you expect a response from this feedback?

  • Terms and conditions
  • Privacy statement
  • GDPR
  • Cookie policy
  • © 2025 ServiceNow. All rights reserved.