What Is ServiceNow Platform Performance? A Plain-Language Guide

What people mean by platform performance

Platform performance is not a product you buy or a module you switch on. It is the name ServiceNow’s documentation gives to a set of tools an administrator already has for finding out why an instance feels slow and what is causing it. The tools record how long each request took, where that time went, which database queries and scripts keep turning up as slow, and which tables would benefit from an index. Used together, they answer the question a frustrated user cannot: is the form slow because of the database, because of a script that runs every time it opens, because of a call to another system, or because of the user’s own browser and network?

That distinction matters because the usual reaction to slowness, asking for more capacity, is not a decision the customer makes on a hosted instance and is often not the fix anyway. Most of the slowness that users report traces back to a query without a suitable index, a business rule or client script doing more work than it needs to, a flow that calls an outside system inside a loop, or a table that has grown far beyond what its reports were designed for. The diagnostic tools exist to point at that cause, so the people who can change the configuration know where to look.

The tools that are already on the instance

The transaction log is the starting point. Every request a user or an integration makes is recorded with its total time and a breakdown of how that time divided between the database, server-side logic, the network and the browser. Reading a single entry tells you where one slow request spent its time. Reading many entries for the same form or list tells you whether the slowness is constant or arrives at certain hours.

Stats Tools, found under System Diagnostics, keep aggregated statistics for slow queries, slow scripts and slow transactions. Rather than listing every request, these views group repeated activity into patterns, so a query that runs thousands of times a day and is slightly slow each time stands out alongside the query that is very slow once. The pattern views can be filtered by application scope, which helps when a custom application is suspected.

The index suggestion engine works from the slow query records. An administrator opens a slow query and asks for a suggestion; the engine proposes an index, can export it for testing on a non-production copy, and after the index is created it watches the query for a period to report whether it helped. It only ever suggests indexes, and only for databases it supports; it does not rewrite scripts or redesign flows.

Beyond these built-in tools there are paid options. The Impact subscription packages include technical health indicators that score an instance on performance, manageability, security, upgradeability and user experience, and a telemetry product that pulls real-time metrics and raises performance alerts. ServiceNow also offers a preventive care service in which its own specialists review an instance. These are worth knowing about, but a team should learn what the free tools say before paying for more.

Who does what with the data

The platform owner or lead administrator usually owns the diagnostic view, because the tools sit behind the admin role and the answers they give lead to configuration changes. Developers read the slow script and slow query patterns to decide what to rewrite. The service desk lead supplies the questions, because they hear the complaints first and know which screens matter most. Database work in the usual sense does not exist for the customer: the vendor runs the database, so the customer’s levers are indexes created through the platform, query design, script design and data volume.

Business stakeholders rarely open any of these views. What they need is a plain statement of what was slow, what the cause turned out to be, and what changed, which is why the later sections of this page spend time on how to ask the question and how to read the answer.

How the diagnosis usually runs

A typical investigation begins with a complaint about one screen or one job. The administrator finds the matching transactions in the log and looks at where the time went. If the database share is large, the slow query patterns show which query it was and whether an index would help. If the server share is large, the slow script patterns point at the business rule, script include or flow doing the work. If the browser or network share dominates, the cause is more likely the amount the page loads, a heavy client script or the user’s connection, and no server-side change will fix it. The answer leads to a change, the change is tested on a sub-production copy, and the same transactions are read again afterwards to confirm the effect.

How this differs from a monitoring tool

External monitoring tools watch an application from the outside: whether it responds, how quickly, and how that changes over the day. The platform’s own diagnostics watch from the inside, at the level of a single request and the queries and scripts it ran. A monitoring tool can tell you the instance has slowed since the last release. The transaction log and the pattern views can tell you which form slowed, which query inside it changed and whether an index or a rewrite is the answer. Teams that run both tend to use the monitor to notice and the diagnostics to explain.

When these tools are worth the time

They earn their place whenever users report slowness and nobody can say why, when a release is suspected of making things worse, when a scheduled job keeps running longer each month, and when someone proposes asking the vendor for a larger instance before the configuration causes have been ruled out. They also support a baseline: a record of normal timings taken in a quiet period, so that a later complaint can be compared against something.

When they are not the first thing to reach for

A new instance with little customisation rarely needs a diagnostic programme; the slowness that appears is usually explained by a known heavy report or an integration still being tuned. A team that already knows the cause, such as a query against a very large table, does not need more diagnosis; it needs a developer and a test instance. And a slowness that only one person experiences is more often a device, a browser extension or a network path than anything the instance records. The tools are most valuable in the middle case: a real, repeated problem whose cause is not yet known.

Deciding the question before switching anything on

Platform performance data is easy to collect and easy to misread, and the two problems share a cause. Teams turn the collection on because they want to see everything, then open a dashboard full of slow transactions and cannot tell which one matters. A better starting point is a single question written in plain words, such as why the change request form is slow for the service desk on weekday mornings, or whether the nightly import is getting longer each month. The question decides which transactions to watch, which time window to use and who should look at the answer.

Once the question is written, check it against three tests. Can the answer be acted on by someone in the team? Does the data exist in the instance for the time period that matters? Would a different answer change a decision? A no to any of these means the question needs rewriting before collection begins. A question that cannot change a decision often generates reports that are read once and then ignored.

Matching each kind of question to a first place to look

The table below gives a practical first stop for the questions teams ask most often. Read the final column with the same care as the others, because it names the gaps where many wrong conclusions begin.

A first collection plan for a team starting out

1. Write the question, the decision it supports, and the person accountable for acting on it.
2. Choose two or three transactions that express the question, and leave the rest unwatched for now.
3. Capture a normal period first, covering at least one full business cycle, so that a later change has something to be compared against.
4. Agree how the team will read the output, including which difference counts as meaningful and which is ordinary variation.
5. Review the data on a set schedule, and close the question once it has changed a decision or been shown not to matter.

This sequence is deliberately narrow. Adding every transaction on day one is a common reason the first review meeting produces no decisions.

Reading the output without overreacting

A single slow transaction is rarely a finding. Look for patterns that repeat across days, users and releases. A transaction that is slow once a week at the same time is more useful than one that was extremely slow once. Treat averages with caution, because a few very slow requests can hide behind a respectable average, and the users who meet those requests will still be frustrated. Where the tool allows it, look at the spread of timings as well as the central value.

Deciding which panels deserve a place on a shared screen is covered in the monitoring dashboard decision design article. Keep a note of what changed in the instance during each period you are comparing. Without that note, a worsening trend will be blamed on whatever is most recent, and a real cause may be missed.

Frequently asked questions for newcomers

Does switching on platform performance collection slow the instance down?

Collection adds some work to each transaction, so it is sensible to check the effect in a non-production copy first and to watch the instance during the first full cycle after enabling it. Tune what is collected to the questions you have, rather than collecting everything by default.

Can the data show which individual user was affected?

Transaction records often identify the user, which is useful for reproduction. It is also personal data, so limit who can see it and for how long, and use role-level grouping for most reporting.

Is this the same as the transaction log?

They overlap. The transaction log is the raw record of each request, while platform performance adds aggregation and recommendations on top. Use the raw log to confirm a specific case and the aggregated view to spot trends.

Who should have access to the recommendations?

The people who can change the affected code or configuration, along with the platform lead. Recommendations are advice, not instructions, and someone accountable should decide whether to act on each one.

Next step

The KPI and metrics guide shows which measures to agree before the first review, and the performance analytics indicator concept explains how trend measures are built.

How to improve ServiceNow platform performance in the order that usually pays off

To improve ServiceNow performance, start with the slowest repeated transactions, find whether the time went to the database, server scripts or the browser, and fix that layer first. In most instances the gains come from queries that need an index, scripts that do too much work and forms that load too much, not from extra capacity.

Work through the layers in this order, because each step is cheaper and safer than the one after it.

1. Slow queries. Take the queries that repeat most often, not only the slowest single one, and test an index or a narrower filter on a non-production copy.
2. Server scripts. Look for business rules that run on every update, queries placed inside loops, and calls to outside systems made while a record is being saved.
3. Forms and lists. Count the fields, related lists and client scripts a heavy form loads, and remove what the role never uses.
4. Reports and scheduled jobs. A dashboard that refreshes many large reports at the start of the working day can slow the same people it is meant to help.
5. Data volume. Tables that keep every record forever grow until each query has more to scan, so agree retention and archiving rules with the data owners.

Change one thing at a time and read the same transactions again afterwards, because two changes at once leave you unable to say which one helped.

Record each change with the transaction, the timing before and after, and the date, so the platform owner can answer a later complaint with evidence. The symptom-led troubleshooting article shows what a typical investigation looks like, and the platform performance guides collect the related explanations. For an outside review, compare the platform performance and upgrade readiness service with a wider health check and assessment.

What is the quickest way to improve ServiceNow performance?

Usually it is fixing the one or two queries or scripts that appear most often in the slow patterns for the screen people complain about. Fixing those removes work from every request on that screen.

Does adding an index always make a ServiceNow query faster?

No. An index helps reads that filter or sort on the indexed fields, but it adds work to every write on that table. Test it on a non-production copy first.

Will archiving old records improve performance?

Often, on large tables, because queries and reports have fewer rows to work through. It helps least when the slow part is a script or an integration call, so confirm where the time goes before planning an archive.

Why a ServiceNow performance reading can mislead you, and how to check it first

A performance reading misleads most often for three reasons: the sample is too small, the two periods being compared carry different loads, or an average hides the runs users remember. Run these checks before you change any configuration. A reading that fails one of them is a prompt to collect more data, not a reason to act.

Start with the sample. One slow transaction shows that something happened, not that it keeps happening. Look for the same form, list or scheduled job across several days and several users. If the slow runs all come from one person, their browser, device or network is a likely cause.

Next, make sure the time windows are comparable. A week after a release set against a quiet week a month earlier tells you as much about record volume as about the release. A saved comparison report that puts both periods side by side makes this check repeatable. If no comparable period exists, say so in the write-up rather than quoting a percentage change.

Then look past the average. A median response that has barely moved can sit alongside a long tail of very slow requests, and the tail is what generates complaints. Read the slowest runs as well as the typical one, and count how many runs were slow.

• Is the pattern present on more than one day and for more than one user?
• Do the two periods have similar record counts and concurrent users?
• Do the slowest runs share one query, script or external call?
• Was the reading taken on the instance the decision applies to?

When the checks pass and one transaction type still accounts for most of the slow time, you have enough to move to a change. When they do not pass, a longer collection window is usually the next step. If the readings are clean but the cause stays unexplained, a performance tuning engagement offers an outside view, and a walkthrough of common causes covers the usual suspects first.