OBLYTECH Logo
Enquire Now
OBLYTECH Logo

OBLYTECH / ServiceNow

ServiceNow Performance: Improving Your IT Operations

Is your ServiceNow instance running slower than a snail on a cold day? Are you experiencing frequent crashes, errors, or unresponsive pages? If so, your ServiceNow performance issues could be costing your business valuable time, money, and resources.

For readers evaluating this topic and deciding what to review next.

ServiceNow performanceServiceNowpractical guide
Discuss this topic

Guide map

A practical framework for servicenow performance.

Define the question and scope

Name the slow transaction, page, or workflow before changing anything.

Make decisions and ownership visible

Record who owns each setting or script that affects response times.

Review evidence and next actions

Compare timings before and after each change to see what it did.

The practical framework

Is your ServiceNow instance running slower than a snail on a cold day? Are you experiencing frequent crashes, errors, or unresponsive pages? If so, your ServiceNow performance issues could be costing your business valuable time, money, and resources.

Poor performance not only frustrates your employees and customers but also hinders productivity and slows down your entire organization. That's why it's crucial to address any performance bottlenecks and optimize your ServiceNow instance for maximum efficiency and responsiveness.

What Causes ServiceNow Performance Issues?

Several factors can contribute to sluggish ServiceNow performance, including:

  • Database Issues: Bloated databases, inefficient queries, and indexing problems can slow down data retrieval and processing.
  • Customization Overloads: Excessive customizations, complex workflows, or poorly written scripts can put a strain on your system resources.
  • Hardware Limitations: Insufficient server capacity or memory can hinder the performance of your ServiceNow instance.
  • Network Congestion: Network bottlenecks or latency issues can affect data transfer speeds and overall responsiveness.
  • User Behavior: A large number of concurrent users or inefficient user practices can also impact performance.

How to Optimize ServiceNow Performance

The good news is that there are several effective strategies you can implement to improve ServiceNow performance:

  1. Regular Maintenance: Regularly review and optimize your database, clean up unused data, and tune your configurations.
  2. Streamline Customizations:  Evaluate your customizations and eliminate unnecessary scripts or workflows.
  3. Upgrade Hardware: If your hardware is outdated or insufficient, consider upgrading to more powerful servers or adding more memory.
  4. Optimize Network: Address network congestion issues by upgrading your network infrastructure or optimizing traffic routing.
  5. Monitor Performance:  Regularly monitor your ServiceNow instance for performance bottlenecks using tools like ServiceNow Performance Analytics.
  6. Train Your Users: Educate your users on best practices for using ServiceNow efficiently to avoid unnecessary load on the system.

Oblytech: Your Partner for ServiceNow Performance Optimization

At Oblytech, we understand the importance of a high-performing ServiceNow instance for your business. Our team of ServiceNow experts can help you diagnose performance issues, identify root causes, and implement effective solutions.

We offer a range of ServiceNow performance optimization services, including:

  • Performance Assessments: A comprehensive review of your ServiceNow instance to identify bottlenecks and areas for improvement.
  • Performance Tuning:  Fine-tuning of configurations, scripts, and database queries to optimize performance.
  • Custom Development:  Development of optimized scripts, workflows, and applications to improve efficiency.
  • Upgrade Assistance: Planning and execution of smooth upgrades to newer ServiceNow versions.
  • Training and Support:  On-site or remote training for your administrators and users on ServiceNow best practices.

Common questions

Questions teams ask about servicenow performance

What should a review establish first?

Start with the question, scope, decision boundary, ownership, and evidence that the reader needs to carry into the next action.

How should the next action be chosen?

Use the article framework to identify the unresolved decision, the responsible group, and the record that will show what happened.

The documented boundary

This article is presented as a practical reference. Apply its recommendations against the specific systems, responsibilities, and evidence available in the organization being reviewed.

Decide which slowness is costing you the most

A ServiceNow instance rarely slows down everywhere at once. One group of users complains that the incident form takes long to save, another says the dashboard never finishes loading, and a third notices that approvals arrive late. Treating these as a single performance problem usually leads to a general tuning exercise that improves nothing a user can feel. Start by sorting the complaints into the transaction or screen each one concerns, and rank them by how many people hit them and how much work stops while they wait.

That ranking is the basis for every later decision. A slow monthly report for a small team can wait. A slow case save that happens hundreds of times a day in the service desk cannot, even if the report looks worse on paper.

The three places the time usually goes

Most slowness falls into one of three places, and each one needs different evidence.

Where the time goesHow it shows up for a userEvidence to collect first
The browser and the user’s networkOnly one site or one location is slow, while others are fineLocation and device pattern of the complaints
Server-side processing in business rules or scriptsSaves and form loads are slow for everyone on a given formSlow transaction records and the scripts that ran during them
Database work and data volumeList views and reports slow down over time or on large tablesSlow query records and the size of the tables involved

A sequence for tracing a slow screen

  1. Reproduce the slow action with a test user who has the same role, and note the exact screen, record and time.
  2. Check whether the slowness appears from another location or device. If it does not, the cause is probably local.
  3. Pull the transaction records for the same window and find the longest entries for the screen in question.
  4. Read the scripts and rules that ran in those transactions, and mark any that query large tables without a tight filter.
  5. Change one thing at a time, then repeat the same reproduction so the effect is measured against the same test.

Changing several things together feels faster, but it leaves nobody knowing which change helped. It also makes it impossible to roll back the one that made things worse.

Where teams lose time on performance work

The first loss is in tuning customizations that were never heavy. Teams sometimes spend a week trimming a script that runs in a few milliseconds while a list view queries a large table with no index in use. The trace records make this easy to avoid, so read them before deciding what to change.

The second loss is in capacity decisions made before the workload is understood. Adding capacity can hide a poor query for a while, and the problem returns as data grows. Ask what the workload looks like before paying for more.

The third loss is in maintenance timing. Changes that rebuild caches or update shared configuration during working hours can make a healthy instance feel slow for a short period. Schedule those changes for quieter windows, and record them, so that a dip in responsiveness can be matched against the change log.

How to tell the work is paying off

Compare the same reproduction before and after each change, and track the complaint volume for the screen in question. Performance dashboards are useful for trend, but they rarely tell you which user action improved. The guide to troubleshooting performance issues approaches the same question more broadly, and the note on business rule governance and performance discusses how Business Rules can affect performance.

Questions to settle before a tuning project starts

Who owns the decision to change a slow business rule?

The application owner who understands what the rule is for should decide. The platform team can measure the effect, but a rule removed only because it is slow may be a control that someone else depends on.

Is it worth a dedicated performance review if users are not complaining?

A scheduled review is worth it when the platform is growing, when a major release is planned, or when a new integration starts writing large volumes. Waiting for complaints can mean the problem has already reached the most important users.

How should a performance fix be tested?

Test on a copy with realistic data volumes, and repeat the reproduction on production during a quiet window after the change. A fix that looks good on a small copy can behave differently once the table is full.

When should a team bring in outside help?

When the trace evidence points to architecture, such as integrations writing into core tables, rather than to a single script or query. A review at that level is faster with someone who has seen the pattern before.

A practical next step

OBLYTECH describes its work in this area on the performance tuning and upgrades page. Contact OBLYTECH about a specific performance concern.

A practical next step

Need a clearer operating model?

OBLYTECH can discuss the questions raised by this guide and the next review step. Use the OBLYTECH contact route to start the conversation.

Useful starting pointBring the current question, scope, ownership concerns, and evidence needs into the first review conversation.

Explore OBLYTECH services

ServiceNow guides on this topic

Guides from the Oblytech ServiceNow library that explain the practice behind this page.

More from the blog

Related reading