ServiceNow Platform Performance Testing and Acceptance Checklist

This checklist explains how to test whether ServiceNow can handle the expected workload. Testing starts with response-time baselines for lists and reports at each record volume to be tested. It then covers slow database queries, concurrent-user load, where transaction time goes, capacity planning and regression testing.

Performance Test Scope and Baselines

Platform Performance Testing verifies that ServiceNow will handle expected workload. Before testing, establish baselines: what is acceptable performance? Set acceptable response times for lists, reports and complex reports at each record volume you need to test, using measurements from the current environment. Define acceptable response times for different scenarios.

Also identify bottleneck scenarios: which operations are most resource-intensive? Complex queries, large reports, many concurrent users. Design performance tests to exercise these scenarios. Identify the current performance level (baseline) so you can measure improvement or degradation over time.

Database Query Performance

ServiceNow’s performance is heavily dependent on database performance. Slow queries cause slow ServiceNow pages. Use database performance monitoring (query profiling, execution plans) to identify slow queries. Set query time targets from your baseline measurements. Queries running well beyond target should be optimised.

Common slow queries include: queries without proper indexes, queries scanning large tables without filters, and queries with complex joins. Review slow queries and add indexes where appropriate. Use the platform’s own diagnostics, such as the slow query and slow transaction logs and the index suggestions they produce, to identify the queries that run often and slowly, then prioritise optimisation of those.

Concurrent User Testing

Performance degrades as concurrent users increase. Load testing simulates multiple users accessing the system simultaneously. Start with baseline load (expected concurrent users during normal hours) and increase to peak load (expected during peak times). Measure response times at each load level.

Identify the breaking point: at what concurrent user count does response time become unacceptable? If acceptable response at 500 users but unacceptable at 1000, that is your capacity ceiling. Plan capacity: if you expect growth beyond your current capacity, invest in performance optimisation or infrastructure scaling.

Where the Time Goes Under Load

On a hosted instance the customer does not see server CPU, memory or disk directly. The platform instead shows where each transaction spent its time, split between database, server processing, network and browser, together with queue and semaphore waits. Watch those splits during the test. A rising database share points at queries, a rising server share points at scripts and business rules, and a rising browser share points at form and portal design. Monitor system resources during performance testing. Identify which resource becomes the bottleneck under load. If CPU maxes out first, the application logic is intensive (consider caching, optimisation, or distributing load). If memory maxes out, there might be a memory leak or excessive data in memory. If disk I/O is the bottleneck, database queries or logging is excessive.

Response Time Distribution and Percentiles

Response times vary: some requests are fast, some are slow. Report not just average response time but percentiles: how long does it take for the slow requests to complete? (P95) How long for the slowest requests? (P99) A system with average response time of 500ms but P99 of 10 seconds is poor, even though the average looks acceptable.

Target: response times for normal operations should meet the average, P95 and P99 targets set by the platform owner from measured baselines. High-complexity operations can take longer, but should be the exception, not the norm.

Scalability and Resource Planning

If the organisation grows (more users, more data), will ServiceNow scale? Scalability testing increases data size and user load progressively and measures how performance changes. If response time increases linearly with load (doubling load doubles response time), the system does not scale well. If response time remains flat despite doubling load, the system scales well.

Use scalability findings to plan infrastructure: if you expect user growth from 500 to 1000 over the next year, performance testing should simulate 1000 concurrent users and verify that infrastructure can handle it. If it cannot, plan for upgrades now.

Real User Monitoring and Synthetic Monitoring

Synthetic monitoring (load testing in a lab) finds issues, but real user monitoring (tracking actual user experience in production) reveals real-world performance. Compare the two: if synthetic tests show good performance but real users report slow response, there might be a production issue (network latency, regional differences, or data-specific slowness).

Implement real user monitoring in production. Collect metrics on how long pages take to load, how long queries take, and where time is spent. Dashboard this data so teams can see if performance is degrading over time. Set alerts if response times exceed thresholds.

Performance Regression Testing

When changes are made to ServiceNow (customisations, plug-ins, configurations), performance can degrade. Regression testing verifies that performance has not degraded. Run performance tests after major changes. If performance has degraded, investigate and fix before deploying to production.

Acceptance Criteria for Performance

Define explicit performance acceptance criteria: response time under X seconds, concurrent users supported Y, no memory leaks during sustained operation. Document these in the acceptance checklist. Before production release, verify that all criteria are met. If not, either fix the issues or formally accept the performance risk (document the decision).

Using performance testing as a release gate rather than a report

Performance testing often ends as a document nobody reads after the release. It becomes useful when it is a gate: a change either meets the agreed evidence or it waits. The release lead needs to know before the change window opens which tests decide the outcome, what result counts as a pass, and who may accept a fail. Without those three answers, the test team and the release team will each interpret a borderline result in their own favour.

The reader here is the person who signs the release, not the person who writes the scripts. The question is narrow: what evidence should exist before a change that affects performance goes to production, and what happens when that evidence is missing or disappointing.

Evidence that decides a release

Each row below is a piece of evidence that should exist before go-live. The pass condition is set by the performance owner and the business owner together, and the table records it in advance so nobody negotiates it after the numbers arrive.

The soak run is often the row skipped. A short functional run can pass even when a background process accumulates work, because the accumulation only becomes visible after many cycles. If the change window is too short for a soak test, the honest option is to release with that risk named, not to call the short run sufficient.

Choosing the test environment

The environment decides how far the results can be trusted. Three choices are common, and each has a specific blind spot.

• A clone of production refreshed for the test is the closest match for data shape, but it can differ in scheduled job timing and integration endpoints, so those must be checked separately.
• A smaller sized sandbox is cheaper and quicker to reset, but its results are only comparable if the data volumes have been scaled and the indexes match production exactly.
• Replaying real activity against a non-production instance captures realistic patterns, but it requires careful handling of personal data and of external calls that must not fire.

Whichever option is chosen, record it in the acceptance record. A result from a sandbox is not a result from production, and a future reader needs to know which one they are looking at.

Ordered procedure for the acceptance run

1. Freeze the build and the data set, and record both identifiers in the test record before the first run.
2. Capture the baseline on the previous build under the same data conditions, not on a remembered figure.
3. Run each scripted journey several times and keep every timing, not only the best one.
4. Compare each journey with its baseline using the tolerance the owner accepted in advance.
5. Review the query profiles and job logs for anything the journey timings would not reveal.
6. Run the soak test, then compare the resource trend against the agreed limit.
7. Present the evidence to the release owner, who records a go, a hold, or a go with a named and accepted risk.

Common reasons acceptance results mislead

A pass can be misleading when the test users are all administrators, when the test data is evenly distributed while production is heavily skewed toward a few large accounts, or when the test ran at a quiet time of day. Each of these makes the test easier than reality. A useful habit is to write one sentence next to each result that says what the test did not cover. If that sentence is long, the pass is weaker than it looks. Release-wide acceptance criteria are a separate artifact, and the release acceptance criteria write-up shows how the two fit together.

Frequently asked questions about performance acceptance

Is a clone of production good enough for load testing?

It is a strong starting point for data shape, and a weak finish for timing. Integration endpoints, scheduled jobs and caching behavior often differ between the clone and production, so those parts of the run need their own checks rather than being assumed from the clone.

How many scripted journeys should the acceptance set include?

Enough to cover the journeys that the business uses most, the journeys that touch the change, and one or two that are known to be slow today. Choose them from usage evidence, not from what is easiest to script.

What do we do when the test passes but users report slowness after release?

Treat the complaint as evidence that the test missed something. Compare the user’s journey with the scripted one, check whether the affected users share a region, a browser or a data profile, and add the missing case to the acceptance set before the next release.

Who is allowed to accept a performance risk?

The business owner of the affected process, with the performance lead’s recommendation on record. The acceptance should name the risk, the expected user impact, and the review date. A risk accepted by silence is not an acceptance.

Next step

The automated test framework guide is the place to look for functional checks that can run alongside this evidence, and the release readiness guide is the place to look for where this gate sits in a wider upgrade plan.