ServiceNow is a complex and powerful platform that forms the backbone of many organizations’ IT service management, operations, and customer service functions. To ensure that your ServiceNow instance continues to operate at peak performance, remains secure, and aligns with industry best practices, regular health checks and audits are crucial. Oblytech’s ServiceNow Health Checks & Audits services provide a comprehensive assessment of your instance, identifying potential issues, vulnerabilities, and opportunities for improvement.
A health check answers a question that dashboards cannot: given how this instance is actually built, configured and used, where are the weaknesses that will cost money, time or control later? Monitoring tells you when something is failing now. An audit tells you whether the platform meets a standard you have set. A health check sits between the two. It reads the configuration, the customizations, the data and the integrations as a whole, and it explains which findings matter most to the business. It is often the right first step when the team cannot say with confidence what the platform looks like, and it is the right input before any large decision such as an upgrade, a new AI capability or a change in the support model.
This page is for the platform owner, the service leader or the executive who must decide whether to commission one. It explains what the review examines, what the output looks like, what the review cannot establish, and how the work is scoped.
A review covers more ground than the configuration screens. The table lists the areas usually included, the question each one answers, and the evidence a reviewer looks for. Not every area is examined in depth in every review. The scope should be agreed before the review starts, and an area that is excluded should be named as excluded in the output.
| Area | Question it answers | Evidence a reviewer looks for |
|---|---|---|
| Configuration and customization | Are the changes made to the standard product understood, documented and still used? | Custom tables, scripts and rules with no owner, or with owners who have left |
| Data integrity | Can the data the platform reports on be trusted? | Duplicate records, empty mandatory fields, and reference data that conflicts with itself |
| Security and access | Do roles and access rules still reflect how people work? | Broad roles, inactive accounts with active privileges, and access rules that have grown by accretion |
| Performance | Where does the instance spend time, and is that time justified? | Slow transactions, heavy scheduled jobs and lists built on large unindexed tables |
| Integrations | Does each connection have an owner, a failure path and a reason to exist? | Connections with no named owner, silent failures and duplicated feeds |
| Upgrade readiness | Would the next release break anything the business relies on? | Customizations that conflict with the standard product and skipped test cycles |
The main output of a health check is a findings register. Each finding is written so that a non-technical sponsor can read it and decide, and so that a technical owner can act on it. A register is more useful than a narrative report because it can be worked through over time, and because each finding carries its own priority and owner. The example below is an illustration of the structure, not a record from a client engagement.
| Finding | Evidence | Business effect if left | Priority | Proposed owner |
|---|---|---|---|---|
| A scheduled import runs during peak hours and slows incident lists | Run times that overlap the morning queue peak in the job history | Slow lists for the service desk at the start of each working day | High | Platform owner with the integration owner |
| Several roles grant write access to a table that only reporting needs to read | Role assignments compared with the access the process actually uses | Unintended changes to records that feed a regulated report | High | Security and access owner |
| A custom catalog item has no named owner and no recent use | Usage history and the change record of its creation | Upgrade effort spent on code nobody needs | Medium | Service owner for the catalog |
| Duplicate location records are created by two integrations | Matching names and identifiers with different source references | Reports count the same site twice and asset ownership is unclear | Medium | Data governance owner |
Priority should reflect business effect and urgency, not the reviewer’s technical interest. A finding that is elegant to fix but affects nobody is usually the lowest on the list.
A review is limited by what it can see. The reviewer works from the access provided, the records available and the interviews held during the work. Where access is restricted, the findings for that area carry lower confidence, and the output should say so. A health check also does not prove that the instance is secure against an attacker, does not replace a penetration test, and does not confirm that the business processes are correct. It shows the state of the platform as built and as used, and it identifies where to look more closely.
It is also worth being clear about what a health check does not fix. The review identifies problems and proposes an order for addressing them. Fixing them is a separate piece of work, usually scoped after the findings are agreed. A buyer who expects remediation in the same engagement should raise that before the review begins, because it changes the scope and the people needed.
Health checks vary widely in size. The number of modules in use, the number of custom components, the number of integrations, the age of the instance and the availability of people to interview all change the effort.
A sensible scoping conversation establishes which areas are in and out, what access is needed for each, and who from your side will answer questions during the review. It also agrees the form of the readout. Some organizations want a single session with the sponsor. Others need a walk-through with each technical owner before the findings reach the sponsor, so that nobody is surprised in the room.
They overlap, and a health check usually covers the readiness question as one of its areas. A dedicated readiness review can go further into the upgrade path and the test plan, and it is often the better choice when an upgrade date is already set.
There is no universal interval. A stable instance with a small customization footprint may need a review less often than one that is changing every month. The trigger events that matter more than the calendar are an upgrade, a change of platform owner, a major new module, and a sustained rise in incidents that nobody can explain.
Parts of it can. Internal teams are usually good at configuration and integration review, because they know the history. An outside reviewer adds value by questioning assumptions that insiders have stopped noticing, and by giving a finding a weight that an internal report may not carry.
A list of the modules in use, the name of each integration owner, a recent list of major changes, and the reports leadership relies on. Those four items let the review start on the questions that matter rather than on discovery.
The register becomes useful when it is turned into a plan. A practical approach groups findings into three sets: those that should be addressed before any other work, those that can be scheduled into the normal change route, and those that need a decision from the business before anyone can act. The third group is often the largest and the most valuable, because it contains the questions the business has been avoiding, such as whether a custom process still matches policy.
Each finding should be closed with evidence, not with a statement that the work was done. A check that is rerun after the fix, and that shows the expected change, is the only reliable proof. That discipline is what turns a one-off review into a platform that improves over time.
A first conversation works best when you bring a short description of why you are asking now. An upcoming upgrade, a new AI use case, a change in support provider or a rising complaint about reliability each points the review at different areas. Add the names of the people who own each major area, and note any part of the platform that nobody currently feels responsible for. Those gaps often produce the most important findings.
For the wider view of how the health check connects to other platform work, the platform health check and readiness page deals with preparing context and evidence for a review, and the CMDB data quality governance page deals with tying data quality rules to owners and remediation. The ServiceNow assessments and readiness page is the wider assessment route. If you want to talk through a specific instance and what a review should cover, discuss your platform health check with the team.
A ServiceNow health check is a structured read of an instance against a written checklist, ending in a ranked list of findings with an owner and a next action for each. It looks at six areas, and most findings come from the first three.
The common triggers are an upgrade on the calendar, a platform that has changed hands, a go-live that has settled, and an audit that will ask how access is controlled. Before an upgrade, the findings that matter most are the customisations that touch upgraded areas; the upgrade and release readiness guides describe how to plan around them. Access findings connect to instance security and access control, and data findings usually lead to CMDB data quality work.
Each finding should state what was seen, why it matters, how risky it is, how much effort the fix takes, and who in your team owns the decision. Findings that mix risk and effort in one score are hard to act on, so keep them separate and sort by risk first.
A health check normally reads configuration and data and reports on them. Fixes are separate decisions that you approve, schedule and test like any other change.
Many teams do it before each major upgrade and again after any large change in ownership or scope, because that is when drift is most likely. For module-specific checks, see ITOM health checks.
Guides from the Oblytech ServiceNow library that explain the practice behind this page.