ServiceNow Platform Performance Governance Model

Performance Standards and Thresholds

Define performance standards: what response time is acceptable for different types of operations? Set targets for page load, list view response and form save with your users. If operations take longer, users perceive the system as slow and avoid it. Define thresholds for alerts: if response time exceeds the target, alert. If CPU utilization exceeds high thresholds, alert. These thresholds trigger investigation and action to fix the issue before users notice performance degradation.

Decision Forums: Performance Review Board

A Performance Review Board (or equivalent forum) meets monthly to review performance data, identify trends, and approve optimization projects. Membership includes: IT Operations (who owns infrastructure), Application Development (who owns code), Database Administration (who owns data), and IT Leadership. The board reviews: weekly performance reports (are we meeting standards?), capacity utilization (are we approaching limits?), incidents related to performance (what caused them?), and optimization opportunities (what could we improve next?). The board prioritizes optimization work: which performance issues have the most business impact, which improvements are most feasible?

Standards for Configuration and Customization

Performance standards should apply to configuration and customization. Examples: business rules and workflows should complete within targets set by the platform owner, and reports within their own target. When developers create new configurations, they are responsible for meeting these standards. If a custom workflow runs too long, that is unacceptable and must be optimized before deployment. Standards are not guidelines; they are requirements. Make developers aware of performance standards during training, document them clearly, and enforce them during code review.

Change Control for Performance-Impacting Changes

Changes to the platform can impact performance: new customization, increased data volume, new integrations. Require impact assessment before large changes: will this change impact performance, and if so, how? For changes with potential performance impact, require testing: simulate realistic workload and confirm performance remains acceptable. If testing shows performance degradation, fix it before production deployment. This prevents surprise performance problems after changes go live. Communicate risk: if a change is expected to temporarily impact performance (during a data migration, for example), let users know when to expect it.

Ownership and Accountability for Performance

Clear ownership is essential. Who owns system performance: is it IT Operations, is it Development, or is it a shared responsibility? Shared ownership can lead to blame-shifting: IT Operations did not allocate enough resources versus Development wrote inefficient code. Best practice: IT Operations owns infrastructure and database performance, Development owns application and customization performance. Both parties are accountable for meeting performance standards. Escalation resolves disputes: if Development blames Operations and vice versa, escalate to leadership to investigate and determine root cause.

Review Cycle and Continuous Monitoring

Monitor performance continuously: collect metrics 24/7, store them for trending analysis, alert on anomalies. Review performance weekly or monthly depending on how often issues arise. Trending analysis shows performance changes over time: is the system getting faster or slower? Performance degradation over weeks indicates a growing problem that needs investigation. Use dashboards to show performance to stakeholders: ops teams see detailed metrics, leadership sees high-level status (green/yellow/red). Visible metrics drive action: if a dashboard shows performance degrading, teams investigate and fix problems.

Capacity Planning for Growth

As your organization grows (more users, more data, more transactions), performance capacity requirements grow. Plan for growth: project user growth, data volume growth, and transaction volume growth over your planning horizon. Work out what the growth means for data volume, archiving, integration load and licensed usage, and when it should be raised with ServiceNow. Plan upgrades in advance: do not wait until the system is completely maxed out and performance crashes. Capacity planning happens on a regular cycle or as part of the infrastructure roadmap. It requires IT Operations, Development, and Finance (who approves spending) to work together.

Budget and Resources for Performance Work

Performance optimization requires investment: database tuning requires specialized skills, optimization projects require developer time, specialist reviews take budget. Without budget allocation, performance work competes with feature development and often loses. Allocate budget proactively: dedicate development capacity to performance work each quarter. Set aside budget for the work that does improve a hosted instance: archiving and data clean-up, rewriting expensive customizations, and specialist review of integrations and scheduled jobs. Treat performance as a deliverable, not as an afterthought. When a project delivers a new feature, it should also deliver performance that meets standards. This mindset shift—performance as equal to functionality—drives better results.

Granting and tracking exceptions to a performance standard

Many teams that set a performance standard eventually meet a case that cannot meet it in the time available. A vendor’s component is slow to load, a regulator requires a full-history report that the standard cannot accommodate, or a data import is too large to finish in the window. Without a defined path for these cases, teams either break the standard silently or stop the work. An exception register gives a third option: a documented, time-limited permission, with a named owner and a condition that ends it. The register is often the part of the governance model that people use, so it is worth designing before the first request arrives.

The lifecycle of a single exception

An exception should move through the same four states every time, so that the register shows its history and not just its current status. A request is written against a named standard, with the measurement attached. It is approved or refused by the person in the table above, and the approval states an end date and the condition that closes it. The exception is reviewed at each release or each review cycle, whichever comes first. It ends when the condition is met, when the end date passes, or when the standard itself is changed. An exception that is still open after its end date has become a standing breach, and should be escalated as one.

Warning signs that the register is being abused

A register that grows steadily and never shrinks is the clearest warning. Other signs are approvals with no measurement attached, exceptions that are renewed without new evidence, and a cluster of exceptions from one team. The last sign often points to a standard that is wrong for that team’s work, which is a reason to revise the standard rather than to keep granting exceptions to it. Revisions should be recorded in the same register so the change is visible to the next reviewer.

Deciding when a standard should change instead

If the same exception keeps being requested for the same kind of work, the standard is probably mis-set. Check whether the target was chosen without measurement, or whether the work has changed in a way the target did not anticipate. Raise the change through the governance forum with the register as evidence. A standard that is revised openly is worth more than one that is quietly ignored in practice, because people trust the numbers they can see changing for a stated reason.

Can an exception be granted by a team lead for a small change?

Only where the register allows it, with the smallest scope and the shortest life. Small changes accumulate, and a team lead’s approval that is not recorded centrally is one that the next audit will not find.

What should happen when the vendor’s fix date slips?

Review the exception at the slipped date with the vendor’s new commitment in writing, and decide whether the user impact has changed. A slip is a new decision, not an automatic extension.

Do exceptions need to be public to the users affected?

At least the affected users should know that a slowdown is expected, when it will end and who to contact. Silence is what turns a known slow screen into a complaint.

How many open exceptions is too many?

No single number applies. Ask whether each open exception has a named owner, a current measurement and a date still ahead. An exception missing any of those is a gap, whatever the total.

A governance model that lists exceptions and standards side by side is easier to maintain when the measurements behind them are settled first. The KPI guide covers how to define those measurements. For the wider case of how these decisions connect to the rest of the section, the platform performance overview is the starting point, and the article on monitoring dashboard decisions covers the reporting side of the same records.