ServiceNow ITOM Discovery licensing. What Discovery finds, your license pays for.

ITOM Visibility, the package carrying Discovery and Service Mapping, is metered on nodes rather than named users. The bill follows what you allow Discovery to see, so scoping is the biggest licensing decision in the program.

How is ServiceNow ITOM Visibility licensed?

ITOM Visibility is licensed per node, a subscription sized on the infrastructure Discovery finds and brings into the CMDB. Named users play no part in the price, so the scope you give Discovery largely decides what you pay.

ServiceNow's order forms call the meter subscription units, and each managed server consumes one. Most buyers still say nodes, and so do we on this page. The Visibility package carries these capabilities:

• Discovery and Service Mapping. The core of the package and the source of almost every counted node.
• Certificate Inventory and Management, and Firewall Inventory and Audit. Security inventories that depend on what Discovery can reach.
• Service Graph Connectors and multicloud discovery. Third party and cloud provider data loaded into the CMDB, which can create or refresh counted records.

Order forms on newer SKUs may name the package differently, so match the capabilities and the unit table on your paper, whatever the product is called.

How is this different from ServiceNow's user licensing?

This inverts the logic of the fulfiller metric on the ITSM side, where roles are the meter. Here the meter is infrastructure, so the most expensive licensing decision in the program is where Discovery is allowed to run.

What counts as a node?

A node is, broadly, a discoverable infrastructure item held in the CMDB as a configuration item. The categories behave differently, and each has its own way of inflating the count.

The ratios come from ServiceNow's ITOM Subscription Unit Overview, and the version your order form references is the one that binds you. Our ITOM licensing guide sets out the full ratio table across both versions.

Why can two identical environments pay very different amounts?

The bill follows configuration policy more than usage. Two identical environments can carry ITOM bills 40 percent apart purely on Discovery schedules, IP range scoping and CMDB retirement rules.

In practice the platform team controls more of the ITOM cost than the negotiators do. The configuration decisions made after signature outweigh anything agreed at the table, so most of this page deals with them.

How should you scope Discovery to control ITOM licensing costs?

Scope Discovery to the services the program maps and monitors, and nothing wider. Discovery runs where its schedules and IP ranges point it, so every range is a spending decision. Each node should earn its place by serving a mapped service, a monitored application or a workflow that consumes the data.

• Scope to services, not subnets. Start from the services the program maps and monitors, and discover the infrastructure behind them. Service Mapping works top down from an entry point, which gives you the list of hosts that matter. The whole network sweep is how a large share of the count ends up delivering nothing.
• Separate visibility from billability. Seeing a device on the network costs nothing, while bringing it into the CMDB as a counted node costs a unit. Discovering everything because the data might be useful someday is a licensing decision, even when it is presented as an operations one.
• Use exclusions inside range sets. Discovery range sets accept excluded addresses and subnets. Lab, test, disaster recovery and retired network segments belong on that list unless a mapped service lives there.
• Review ranges on a schedule. Scopes set at go live drift as networks change. An annual range review against the service portfolio is the cheapest audit defense the program has.

Why we disagree with discovering everything first and cleaning up later

Implementation partners often recommend a broad first sweep to build a complete CMDB, with scoping to follow once the data settles. We advise against it. In the reviews we led, the cleanup rarely followed, because the counted population became the renewal baseline and no one was made responsible for cutting it.

The better course is to set scope before the first production schedule runs. Agree the service list with the operations lead, build ranges and exclusions from it, and grow the scope when a new service is onboarded. A wider sweep can still run as a one off audit, provided its results never reach counted classes.

Why do cloud and ephemeral resources inflate the ITOM node count?

Cloud discovery records every resource it sees on every pass, and the record outlives the resource. Autoscaling groups, short lived instances and container hosts each become a configuration item that persists after the resource dies. Without lifecycle rules the CMDB fills with ghosts, and every ghost inside the counting window is a counted node at the next true up.

This is how an environment can hold its physical footprint flat and still watch the node count climb quarter after quarter. The programs that skipped lifecycle control paid for that growth at renewal, while their actual infrastructure stayed the same size.

How long does a dead cloud resource keep counting?

The licensing application's default criteria count CIs that are not retired and were discovered within the last 90 days. That window is short for a physical server and long for an autoscaling group that replaces its instances every day, where 90 days of dead instances can sit in the count at once.

Which lifecycle rules keep cloud ghosts out of the count?

The control is mechanical, and it has four parts.

1. Retirement rules with a window. Mark short lived resources absent after a defined period without discovery, then retire them so they leave the counted population well before the 90 day default does it for you.
2. Reconciliation against provider inventories. Compare the CMDB with the provider's own list, for example AWS Config or Azure Resource Graph, every quarter. Anything in the CMDB and not in the provider is a ghost.
3. A deliberate decision on ephemeral infrastructure. Decide whether it belongs in the count at all, or whether monitoring is better served at the cluster and service level.
4. A named owner for each cloud account. New accounts get connected to Discovery quickly. Someone has to confirm the lifecycle rules apply before the first scan.

Check which container ratio your contract carries. On SKUs introduced April 9, 2026, ten containers consume one unit instead of three, which changes whether container level discovery is worth paying for. Buyers on older paper keep the older ratio until they renegotiate it.

How does CMDB hygiene change what you pay for ITOM Visibility?

Directly, because the CMDB is the system of record the node count flows from. Every data quality problem is also a billing problem, which makes CMDB hygiene a licensing control as well as a data quality matter.

• Duplicates. Overlapping discovery sources, such as Discovery and a Service Graph Connector that identify the same server differently, count it twice.
• Stale items. Records for decommissioned infrastructure keep counting while a connector or a leftover schedule still refreshes them, and at least until the recent discovery window closes. Retiring them at decommission ends that at once.
• Reclassified devices. Items moved between classes can linger in counted categories.

The platform team sees these as data quality debt, while the license bill records them as growth. The fix is to give the count an owner. Someone with a financial mandate reconciles the counted node population quarterly, retires the stale records, removes the duplicates and signs the number the subscription is sized against.

It is the same discipline as the App Engine custom table inventory and the fulfiller role reconciliation, applied to infrastructure. It is also the first artifact a ServiceNow license review asks for on the ITOM line.

How do you check your own node count?

Use the platform's own reports first, then trace every surprising number to the schedule or source that created it.

• Licensable CI report. In the ITOM License application, open Report ITOM Licensable CIs and select Visibility or Discovery. It needs the sn_itom_license.reader role and shows the population ServiceNow meters.
• Discovery schedules and range sets. Export every schedule with its ranges and exclusions. Any schedule that targets a whole subnet needs a service behind it.
• CMDB Health dashboard. The correctness score covers duplicate, orphan and stale CIs, which is most of the cleanup list.
• Identification and Reconciliation rules. Duplicates usually trace back to rules that let two sources create separate records for one server.
• CMDB Data Manager policies. Confirm that retire and archive policies exist and run on schedule.

What does a scoping and hygiene pass save?

Enough to change the renewal, because every node removed comes off the recurring subscription. The example below is hypothetical, with round numbers, to show how the cleanup adds up.

Say your order form covers 4,000 Visibility nodes at an effective $150 per node a year, $600,000 in total. A reconciliation against mapped services finds four groups of nodes that serve nothing.

The cleaned count is 3,000 nodes, a 25 percent reduction. The annual subscription falls from $600,000 to $450,000 before any discount is discussed, and over a three year term at the same rate the saving comes to $450,000. None of the removed nodes supported anything the operations team used.

What have we seen in ServiceNow ITOM reviews from 2024 to 2026?

Across roughly 20 to 30 ServiceNow ITOM reviews I led between 2024 and 2026, the recurring finding was Discovery pointed at the whole network with no scoping. That inflated the count well past what the program used, and three patterns repeated.

• 20 to 35 percent of nodes had no operational value. They were never used in any mapped service, discovered because a range included them and retained because no one retired them.
• 15 to 30 percent of spend was recoverable. Most environments could cut that much through a scoping pass, lifecycle rules and a CMDB hygiene cycle before the renewal. In most cases no one had been made responsible for the work.
• CMDB drift held the count up. Stale and duplicate configuration items kept counts, and therefore cost, above reality quarter after quarter.

The programs that recovered the spend all did the same three things. They reconciled the count before the renewal, brought the evidence to the table and negotiated the subscription against the cleaned number. The wider platform sequencing sits in the CIO negotiation guide.

A node that feeds no service, monitor or workflow is paying rent for nothing, and it pays again at every renewal.

How do you negotiate ITOM Visibility at renewal?

Negotiate on the cleaned count first and the discount last. Bring the reconciled node list, the mapping of nodes to services and your effective price per node. Then size the subscription against that evidence inside the wider platform deal.

What will the account team say, and how should you reply?

What contract terms should you ask for?

• A definition of a counted node. Tie it to CIs that are operational and recently discovered, with the window stated, so retired, absent and stale records are excluded in writing and independent of a default setting that can change.
• A named ratio table. Reference the Subscription Unit Overview version that applies, so conversion rates cannot change during the term.
• A measurement method. Agree when the count is taken and a correction period before any true up claim.
• Expansion bands at a locked unit price. Growth is priced in advance, and you pay only when the count reaches it.
• Reallocation rights. The right to move units between Visibility and other ITOM products at renewal when the mix changes.

How does the approach differ for a small and a large environment?

A company with a few hundred servers in one data center usually has a stable count. Its savings come from one careful scoping pass and a retire policy that runs, and a yearly review is enough.

A hybrid environment with several cloud accounts and container platforms changes every week. There the lifecycle rules and the quarterly reconciliation matter more than the initial scope, and the ratio table on the order form becomes a real cost term.

For the audit side of the same count, see how to avoid true up surprises.

What to do next

1. Export the counted node population. Join it to the mapped services. Every node serving nothing is a candidate for removal from scope.
2. Rescope Discovery to the service portfolio. Set ranges, exclusions and schedules that cover what the program uses.
3. Install lifecycle rules for cloud and ephemeral resources. Set retirement windows and a quarterly reconciliation against provider inventories.
4. Run the CMDB hygiene cycle. Remove duplicates, retire stale records, reclassify, and put a named owner on the quarterly count.
5. Take the cleaned count into the renewal. Size the subscription against it inside the wider platform negotiation, where there is room to trade. Our ServiceNow practice and the rightsizing tool run the reconciliation with you.

Frequently asked questions