Somewhere in most ServiceNow programmes there is a slide with a Discovery coverage figure on it. Ninety-four percent. Ninety-seven. The number is not fabricated — it is computed from real data and it is arithmetically correct. It is also, in the great majority of cases, answering a question nobody asked.
Coverage is a fraction. The interesting half is the denominator, and the denominator is almost always a set that Discovery itself produced.
What the number usually measures
The common construction is: of the configuration items in the CMDB, what proportion were successfully scanned in the last N days. That is a useful operational metric — it tells you whether your schedules are running and your credentials still work. It says nothing whatsoever about whether the CMDB contains the estate.
Put plainly: if Discovery has never reached a segment, nothing from that segment is in the CMDB, so nothing from it appears in the denominator either. A network you cannot see scores one hundred percent coverage, because it contributes zero to both halves of the fraction.
This is not a subtle statistical point. It is the single most common reason a CMDB that reports excellent health is not trusted by the people who have to use it.
Four ways the denominator flatters
One: the estate defines itself
Unless the denominator comes from a source outside ServiceNow — an IP address management system, a network team’s authoritative subnet list, a cloud provider’s own account inventory, a procurement or asset register — it is circular. The only honest coverage figure compares what Discovery found against what something else says exists.
The comparison is usually uncomfortable the first time it is run. That discomfort is the value.
Two: credential failures look like absence
A device that responds to a port scan but rejects every credential gets classified and then stalls. Depending on how it is counted, it may appear as an unclassified CI, as a device with almost no attributes, or not at all. In every case the estate contains something the CMDB cannot describe.
Credential failure rates are worth watching on their own, because they cluster. They cluster on the older systems, the ones a departed administrator built, the ones outside the standard build — which is to say, disproportionately the systems most likely to be involved in an incident.
Three: ranges that were never in a schedule
Discovery scans the IP ranges it is told to scan. Ranges get added when a project needs them and are rarely reviewed afterwards. Acquisitions, new data centre segments, a cloud account opened by a team that did not tell anyone, a DR site that only exists in someone’s runbook — none of these appear as gaps. They appear as nothing.
The check is mechanical and worth doing annually: take the authoritative list of subnets in use, diff it against the ranges configured in Discovery schedules, and look at what falls out.
Four: stale is not the same as missing
A CI discovered eighteen months ago and never re-scanned is still a row in the table. It counts toward completeness. It may describe a server that was decommissioned a year ago, or one whose role, owner and dependencies have all changed since.
Freshness is a different axis from coverage and it degrades silently. A CMDB can get less accurate while every dashboard on it improves, because retirement is nobody’s job and creation is everybody’s.
What to measure instead
Five figures, none of which is a single headline percentage, and all of which are actionable:
- External reconciliation. Devices found by Discovery as a proportion of devices in an authoritative external source, per source. Report it per source, because the gaps differ by source and the mix tells you where to look.
- Credential success rate, trended, and broken down by the group of devices that fails. A flat 8% failure rate that is always the same 8% is a different problem from one that moves.
- Range coverage. Subnets in the authoritative network inventory that appear in no Discovery schedule.
- Freshness distribution. Not the mean — the tail. How many CIs have not been seen in ninety days, and are any of them supporting something that matters?
- Reconciliation conflicts. Where two data sources disagree about the same CI and the precedence rules are silently picking a winner. These are invisible until someone notices the CMDB says one thing and the console says another.
Where Discovery is the wrong instrument
Agentless scanning is not the only way to populate a CMDB, and for parts of a modern estate it is the harder way.
Endpoints that are rarely on the corporate network, roam, or sit behind a segment the MID Server cannot reach are better served by an agent or by an existing endpoint management system that already has the data. Cloud resources are better read through the provider’s own APIs than probed. Where an authoritative system of record already exists for a class of asset, importing from it and reconciling is usually cheaper and more accurate than rediscovering it.
The design question is not “how do we get Discovery to reach everything”. It is “for each class of CI, what is the authoritative source, and what is the mechanism that keeps it current”. Discovery is one of several answers, and being clear about which classes it owns is the thing that makes reconciliation behave.
The order to fix it in
Establish an external denominator first, even a rough one, because everything else is uninterpretable without it. Then close credential failures, because they are usually the largest single recoverable gap and the cheapest to act on. Then reconcile schedule ranges against the network inventory. Then, and only then, attend to freshness and retirement, which is the ongoing discipline rather than the remediation.
Reversing that order is common and produces a lot of effort for a number that does not move, because the work is being aimed at the visible part of the estate rather than the invisible one.
What to do with the honest number
It will be lower than the one on the slide, and that is the point of computing it. A CMDB programme reporting ninety-four percent has no argument for further investment; one reporting sixty-one percent against an external denominator, with the gap named and attributed, has a fundable plan.
The uncomfortable version is the one that gets the work done.