A CMDB Health score is useful only when it points to data problems that can be fixed. Chasing a higher percentage without understanding the underlying rules can produce cosmetic improvements while incidents, changes, service mapping, and automation continue to rely on incomplete or conflicting configuration data. The goal is not a perfect dashboard; it is a CMDB whose records and relationships are trustworthy enough for operational decisions.
Current ServiceNow CMDB Health evaluates more than the traditional “three Cs.” Completeness, Correctness, and Compliance remain core KPIs, and current documentation also includes relationship health. For the CIS – Data Foundations path, understanding what each category actually tests is more important than memorizing a score.
Completeness asks whether required information is present
Completeness evaluates missing required and recommended fields. Required fields are tied to mandatory attributes in the class schema, while recommended-field rules can identify additional data that improves operational usefulness even when the platform does not require it for record creation.
The key is to choose requirements with a business reason. Marking dozens of fields mandatory can raise administrative burden without improving outcomes. A server class may genuinely need owner, environment, location, or support group for routing and accountability, but another attribute may be optional because no downstream process uses it.
When completeness is poor, investigate the source. If discovered CIs repeatedly lack an owner, the fix may belong in an authoritative business data integration rather than manual CMDB editing. Health rules should reveal process gaps, not create a permanent queue of corrections that automation later overwrites.
Correctness looks for integrity problems, not simply missing values
Correctness includes metrics such as duplicate, orphan, and stale CIs. A record can be complete yet incorrect because it represents an asset that no longer exists, duplicates another CI, or lacks the relationships expected for its class.
Duplicate detection relies on identification rules, which connects CMDB Health directly to IRE design. A duplicate metric is not solved sustainably by merging records every week; the ingestion path that creates new duplicates must be corrected. Staleness has a similar pattern. Deleting old records may improve the score temporarily, but administrators should determine why the source stopped updating them and what lifecycle state should apply.
Orphan rules require context. A CI without a relationship may be invalid in one class and perfectly acceptable in another. Configure rules to reflect the intended model rather than assuming every object must be connected in the same way.
Compliance checks whether CI data meets defined expectations
Compliance in CMDB Health is based on audit results that compare actual values with expected values defined through audit configuration. This can answer questions such as whether a class follows an internal configuration standard or whether particular attributes match an approved template.
Compliance is not automatically meaningful just because a rule can be written. Choose checks that represent real policy or operational requirements. If a rule changes frequently or is not owned by anyone, failed results become noise. If it represents a genuine security, regulatory, or configuration requirement, assign remediation responsibility and track failures to closure.
Current ServiceNow documentation notes that audit functionality must be activated for the compliance KPI to produce results. An empty compliance view may therefore be a configuration issue rather than evidence that every CI is compliant.
Relationship health matters because services depend on the graph
Current CMDB Health also evaluates relationship quality. Duplicate and orphan relationships can create misleading topology, while invalid hosting, containment, or suggested relationships can weaken service mapping and impact analysis.
Relationship defects are often harder to notice than blank fields. A server record may look healthy in isolation while pointing to the wrong application service. During an outage, that one incorrect edge can misstate business impact. Relationship health should therefore be reviewed with the same seriousness as CI attributes.
Use class and CSDM expectations to determine which relationships are required or valid. Do not add links merely to eliminate an orphan warning; create relationships only when they describe the real architecture or service model.
Enable and schedule the health jobs before trusting the dashboard
Current ServiceNow documentation states that base-system CMDB Health dashboard jobs are disabled by default. The required score-calculation jobs must be enabled and configured for the organization to collect and aggregate current results. If jobs are not running, the dashboard can be empty or stale even though the underlying data is changing.
Choose schedules that match the rate of change and the cost of processing. A rapidly changing cloud environment may need more frequent evaluation than a small static estate. Coordinate health jobs with discovery, imports, and other ingestion schedules so the dashboard does not repeatedly measure the database halfway through a large refresh.
Monitor job completion as part of the health program. A beautiful dashboard based on a failed or outdated calculation is worse than an obvious error because users may trust it.
Use failure thresholds as processing controls, not score targets
CMDB Health metrics can use failure thresholds that stop processing when the number of failing CIs reaches a configured limit. This protects processing from very large failure sets, but it also means a “Max Failures” condition should trigger investigation of the underlying data rather than an automatic increase of the threshold.
If tens of thousands of records fail the same completeness rule, ask whether the rule was configured appropriately, whether an upstream source stopped sending a field, or whether the class population contains data it should not. Raising the threshold can make the job run longer without improving the CMDB.
Thresholds are operational safety controls. Remediation should focus on the failure pattern and source of bad data.
Create remediation ownership for health failures
Current CMDB Health preferences can create tasks when CIs fail configured tests. That is useful only if the tasks reach groups that can correct the source of the failure. Sending every health defect to a central CMDB team creates a bottleneck and hides ownership.
Route problems according to their cause. Discovery gaps may belong to infrastructure teams. Missing business ownership may belong to application or service owners. Duplicate CIs may require integration engineering. Compliance failures may belong to security or platform governance. The CMDB team should coordinate standards and root-cause analysis rather than manually editing every record.
Track recurring failure categories. If the same class produces the same task every cycle, fix the ingestion or modeling rule instead of treating the repeated task as normal operations.
Measure trends and business impact, not only the aggregate score
An aggregate health percentage can improve while a critical service becomes worse. Segment health by important classes, services, data sources, and ownership groups. A 98% completeness score means little if the missing 2% includes every production database owner or every critical application relationship.
Pair health metrics with operational outcomes. Are change-impact assessments becoming more accurate? Are incident assignment groups populated correctly from CI data? Are duplicate-related investigation errors declining? Does service mapping cover the services the business considers critical? These measures prove that healthier data is creating value.
Scope is as important as the percentage. A global score can hide a weak production class inside a much larger population of low-impact CIs. Define health groups or reporting slices around services, classes, environments, data sources, and ownership domains that correspond to real operating responsibility. A platform team can then see whether the CIs it controls are improving instead of relying on a single enterprise average.
Prioritize failures by consequence as well as volume. One missing owner on the configuration item for a critical payment service may matter more than hundreds of optional-field failures on test devices. Likewise, a wrong relationship on a high-impact application can undermine change assessment even when overall relationship health is high. Health governance should therefore identify critical populations and apply stronger expectations where bad data creates greater operational risk.
Be careful when changing scoring rules. Tightening a completeness requirement can make the dashboard appear to deteriorate even when the underlying records did not change; loosening a rule can make the score rise without any remediation. Record rule changes alongside trend reporting so stakeholders can distinguish genuine data improvement from a change in measurement.
Use remediation sequencing rather than trying to fix every KPI at once. Identification defects that create duplicates can undermine later completeness and relationship work because teams may be improving the wrong record. Stale-source problems can make compliance results meaningless. In many environments, the practical order is to stabilize ingestion and identity first, address critical lifecycle and relationship defects next, and then refine field-level quality. The exact sequence depends on the business use case, but dependencies among failures should shape the backlog.
The wider ServiceNow platform depends on configuration data in many processes, so CMDB quality should be evaluated by the decisions it improves.
Close the loop from dashboard failure to source correction
The most mature CMDB Health programs treat each metric as a diagnostic signal. A completeness failure asks which source should populate the field. A duplicate asks whether identification rules and ingestion paths agree. A stale CI asks whether lifecycle handling is working. A relationship failure asks whether the service model or discovery process is incorrect.
That feedback loop is the difference between maintenance and improvement. Cleaning records manually can make today’s dashboard greener. Correcting the source, rule, or ownership model prevents tomorrow’s failure and raises trust in the CMDB over time.