CMDB Health KPIs & Data Manager

Section 1

CMDB Health — The Quality Scorecard

CMDB Health is ServiceNow's built-in framework for measuring data quality across your CMDB. It evaluates CIs across five dimensions and produces a health score for each CI class. This score tells you — at a glance — where your data quality is strong and where it needs attention.

Navigate to Configuration → CMDB Health → Dashboard to access it.

📊

Analogy — CMDB Health as a Credit Score Just as a credit score combines multiple financial factors (payment history, debt level, credit age) into a single number, CMDB Health combines multiple data quality factors into a single score per CI class. A low score tells you there's a problem; the sub-scores tell you exactly which dimension needs improvement. Like a credit score, CMDB Health improves gradually as you fix underlying issues — there's no instant fix.

Section 2

CMDB Health Dimensions

CMDB Health evaluates each CI class across health dimensions. The official ServiceNow model defines three top-level KPIs: Completeness, Correctness, and Compliance. Within the dashboard, Correctness is further broken down into sub-metrics including Staleness and Duplicate, which are surfaced as separate scored dimensions. You will see five scores on the dashboard, but Staleness and Duplicate are components of Correctness, not independent top-level KPIs:

Dimension	What It Measures	Example Failure
Completeness	Are required fields populated? Are mandatory attributes present on each CI?	40% of server CIs have no support_group or owned_by value
Compliance	Do CI values conform to defined rules? Are there invalid values, format violations, or field constraint breaches?	IP address field contains "Unknown" (string) instead of a valid IP format
Correctness	Is the data accurate and consistent? Does it match authoritative sources?	Discovery reports ip_address=10.0.1.5 but CI shows ip_address=10.0.1.6
Staleness	How recently was the CI data last verified or updated? Is it current?	80% of network device CIs haven't been discovered in over 90 days
Duplicate	Are there duplicate CI records for the same physical or logical entity?	25 server CIs flagged as potential duplicates awaiting deduplication

💡

Key Concept — Each Dimension Is a Separate Signal A CI class can score 95% on Completeness but 40% on Staleness (all fields are filled in, but no Discovery has run in months). Or it can score well on Staleness but poorly on Duplicates (Discovery runs daily but keeps creating duplicates because Identification Rules are broken). The dashboard shows each as a separate score. Exam note: official ServiceNow documentation groups Staleness and Duplicate as sub-metrics under the Correctness KPI — not independent top-level dimensions.

Section 3

CMDB Health Rules — Configuring What Gets Measured

CMDB Health works by evaluating Health Rules against CIs. A Health Rule defines:

Which CI class the rule applies to
Which dimension it measures (Completeness, Compliance, Correctness, Staleness, Duplicate)
The specific check to perform (e.g., "support_group must not be null")
The weight of this rule in the overall health score
The threshold for passing vs. failing

Out-of-Box Health Rules

ServiceNow ships hundreds of pre-configured Health Rules covering all major CI classes. These rules encode industry best practices for CMDB data quality. You can:

Activate or deactivate existing rules
Adjust the weight of rules to reflect your organization's priorities
Create custom rules for organization-specific requirements

Creating a Custom Health Rule

Navigate to Configuration → CMDB Health → Health Rules → New. Define:

Name: Descriptive name for the rule
CI class: Which class to evaluate
Dimension: Which of the five dimensions
Condition: The ServiceNow filter that defines "passing" CIs
Weight: 1-100, reflecting importance relative to other rules

⚠

Exam Pattern — Health Rules Are Configurable CMDB Health is not a fixed measurement — it reflects what your organization considers important. A Health Rule that requires "location" field populated matters for physical servers (location = data center rack) but may be irrelevant for cloud VMs (they don't have a physical location). The exam may ask why a Health Rule should be deactivated for a specific CI class — the answer is that the rule doesn't apply to that class's characteristics.

Section 4

Health Scoring, Thresholds, and Dashboard Navigation

CMDB Health produces scores from 0-100 for each dimension and an overall weighted score. Color coding makes the dashboard immediately interpretable:

Green (80-100): Healthy — data quality meets or exceeds targets
Yellow (60-79): Caution — attention needed; quality is declining or below target
Red (0-59): Critical — significant data quality issues requiring immediate remediation

The CMDB Health Dashboard — Key Sections

Overall Health by CI Class: Table showing each CI class with its overall score and per-dimension scores. Sort by lowest score to prioritize remediation.
Health Trend: Chart showing how scores have changed over time. Declining trends trigger investigation; improving trends validate remediation efforts.
Top Issues: Specific failing Health Rules with CI count. "1,234 Windows server CIs are missing support_group" — actionable, not abstract.
Drill-Down: Click any score to see the specific CIs that failed each Health Rule, enabling targeted remediation.

💡

Tip — Use the Drill-Down for Targeted Remediation Don't try to fix all CIs in a class when a Health score is low. Use the Health Dashboard drill-down to find the specific failing CIs and the specific failing rules. If 500 of 2,000 server CIs are failing the "support_group required" rule, start with those 500 — not all 2,000. Targeted remediation is more efficient and shows measurable improvement faster.

Section 5

Staleness — The Time-Dimension of Data Quality

Staleness is unique among the five dimensions: it measures not what data is in the CMDB, but how recently that data was verified. A CI can have all fields populated and zero duplicates, but if it hasn't been scanned in 6 months, you can't trust the data is still current.

How Staleness Is Calculated

Staleness uses the last_discovered field on CIs. A Health Rule for Staleness might say: "Flag this CI as stale if last_discovered is more than 30 days ago." The threshold varies by CI class:

High-change environments (cloud VMs, containers): 24-hour staleness threshold
Stable environments (physical servers, network devices): 30-90 day threshold
Non-discoverable CIs (contracts, physical assets): 90-365 day threshold with manual review trigger

Stale CIs and Decommission Detection

Staleness also helps detect decommissioned CIs. If a server is decommissioned without going through the proper CI lifecycle process, Discovery stops finding it. The last_discovered timestamp stops updating. Eventually, the Staleness score drops, triggering investigation: "Is this server actually decommissioned? Should its operational_status be set to Retired?"

💡

Key Concept — Staleness Is the Health Signal for Discovery Gaps When Staleness scores drop across a specific CI class, investigate: Is Discovery not running for that IP range? Did a subnet change? Did Discovery credentials expire? A sudden staleness increase for a whole class often signals a Discovery configuration problem, not a data quality issue.

Section 6

CMDB Data Manager — Bulk CI Lifecycle Management

CMDB Health tells you what is wrong with your data. CMDB Data Manager is the tool that helps you fix it at scale — and more importantly, helps you manage what happens to CI data over time through automated lifecycle policies.

Navigate to Configuration → CMDB Data Manager.

What CMDB Data Manager Does

Aging: Automatically moves CIs through lifecycle stages based on how long since they were last discovered. A CI not seen in 60 days might be moved to "Review" status; not seen in 90 days might be automatically Retired.
Archiving: Moves old, inactive CIs out of the primary CMDB tables into archive tables. Keeps the CMDB lean and responsive. Archived CIs can be restored if needed.
Deletion: Permanently removes CI records that have been archived for a configured period and are confirmed no longer needed. Irreversible.
Field cleanup: Bulk update of field values across many CIs. For example: set all CIs with location="Unknown" to a specific default location, or blank out a deprecated field across an entire CI class.

Data Manager Policies

CMDB Data Manager works through Policies — configured rules that define what action to take, under what conditions, and for which CI class. A Policy might say: "For class cmdb_ci_server: if last_discovered is older than 90 days AND operational_status = Operational, change operational_status to Absent."

⚠

Warning — Test Aging Policies on a Small Subset First CMDB Data Manager policies can affect thousands of CIs automatically. A misconfigured aging policy that sets all servers to "Retired" instead of "Absent" is catastrophic — it breaks ITSM workflows, incident routing, and CSDM impact analysis for every affected CI. Always test policies with a small scoped dataset before enabling auto-execution on the entire CI class.

Section 7

CI Lifecycle States — Operational Status Values

A CI's operational_status field tracks where it is in its lifecycle. Understanding these states is critical for both Data Manager configuration and exam questions:

Status Value	Meaning	CMDB Health Impact
1 — Operational	CI is in active production use and should be discoverable	All Health Rules fully apply. Staleness monitored strictly.
2 — Non-Operational	CI exists but is not actively in service (e.g., in storage, powered off)	Health Rules may apply with relaxed staleness thresholds
3 — Repair in Progress	CI is being serviced or repaired	Staleness exemption applies — known reason for not being discovered
4 — DR Standby	CI is a disaster recovery standby, not normally in production	Staleness threshold extended — DR systems may not be scanned as frequently
5 — Ready	CI is provisioned and ready but not yet in active production (e.g., pre-deployment staging)	May be excluded from some Staleness rules depending on organization policy
6 — Retired	CI has been formally decommissioned. No longer in use. Kept for audit history.	Health Rules largely suspended. Staleness monitoring not relevant.
7 — Pipeline	CI is in procurement or development pipeline — ordered but not yet delivered	Discovery doesn't apply. Health Rules scoped to asset tracking only.
8 — Catalog	CI is a catalog template or standard build — not an active deployed instance	Not tracked by Discovery. Excluded from Staleness measurement.

⚠

Exam Trap — Absent vs. Retired Absent is an operational_status value that CMDB Data Manager sets on CIs it did not find in the last Discovery scan. It signals "investigate — this CI may be decommissioned, offline, or have a Discovery coverage gap." It is NOT slot 5 in the standard choice list (slot 5 = Ready). Absent is a distinct value added by CMDB Data Manager. Retired (6) = formally decommissioned through the change management process — a deliberate, governed state change. Data Manager sets stale CIs to Absent first (letting humans investigate), then to Retired only after confirmation. Never auto-retire without human review.

Section 8

CMDB Health as Executive KPIs

CMDB Health scores serve as KPIs for executive reporting on CMDB program success. The CMDB Manager uses these to report program health to the CMDB Owner and IT leadership:

Overall CMDB Health Score: Single number summarizing CMDB quality. Target: 80+
Completeness rate by critical CI class: "92% of Production server CIs have all required fields"
Staleness rate: "98% of CIs were discovered within the last 30 days"
Duplicate rate: "0.3% duplicate rate across all CI classes" (target: <1%)
CSDM completeness: "85% of Business Applications have Application Services linked"

Trend reporting is more useful than point-in-time scores: showing that the Completeness score improved from 65% to 82% over the quarter demonstrates the governance program is working.

Exam Quick Reference

CMDB Health KPIs & Data Manager — Key Facts

Three CMDB Health KPIs: Completeness, Compliance, Correctness. The dashboard also surfaces Staleness and Duplicate as separate scores — these are sub-metrics of Correctness, not independent top-level KPIs.
Health Rules define what's measured. Configurable per class. ServiceNow ships hundreds out-of-box.
Traffic light scoring: Green (80-100) = healthy, Yellow (60-79) = caution, Red (0-59) = critical.
Staleness uses last_discovered field. Threshold varies by CI class and environment volatility.
Absent = operational_status set by CMDB Data Manager when CI not found in Discovery. Requires investigation. NOT the same as Retired. Not slot 5 (slot 5 = Ready in OOTB).
Retired (6) = formally decommissioned through change management. Deliberate state.
operational_status OOTB values: 1=Operational, 2=Non-Operational, 3=Repair in Progress, 4=DR Standby, 5=Ready, 6=Retired, 7=Pipeline, 8=Catalog.
CMDB Data Manager provides bulk CI lifecycle management: aging, archiving, deletion, field cleanup.
Data Manager Policies = automated rules for moving CIs through lifecycle states based on conditions.
Test Data Manager policies on a small subset before bulk execution — misconfiguration affects thousands of CIs.
Use Health Dashboard drill-down to find specific failing CIs for targeted remediation — don't try to fix all at once.

Term Grid

CMDB Health

ServiceNow framework measuring CMDB data quality across five dimensions (Completeness, Compliance, Correctness, Staleness, Duplicate). Produces 0-100 scores per CI class. Primary governance measurement tool.

Health Rule

Configurable evaluation rule within CMDB Health. Defines which CI class to evaluate, which dimension to measure, the specific condition, and the weight in overall score calculation.

Staleness (Health Dimension)

CMDB Health dimension measuring how recently CI data was last verified by Discovery. Uses the last_discovered field. Stale CIs may be decommissioned or have Discovery coverage gaps.

CMDB Data Manager

ServiceNow tool for bulk CI lifecycle management. Supports aging (auto-setting operational_status based on staleness), archiving, deletion, and field cleanup across large CI populations.

Absent (operational_status)

Operational status set by CMDB Data Manager when Discovery does not find the CI on its last scan. Not OOTB slot 5 (that is Ready). Indicates the CI may be decommissioned, offline, or have a Discovery coverage gap. Requires human investigation before proceeding to Retired (6).

Data Manager Policy

Configured rule in CMDB Data Manager defining automated CI lifecycle actions (e.g., "set operational_status=Absent if last_discovered > 90 days"). Can run on a schedule or on-demand.

Exam Checkpoint

Practice Questions

Click any question to reveal the answer and explanation.

1. The CMDB Health dashboard shows a Completeness score of 45% (Red) for cmdb_ci_linux_server. The CMDB Manager wants to understand specifically which fields are failing and for which CIs. What should she do?

A) Run a new Discovery scan to repopulate missing fields

B) Use the CMDB Health dashboard drill-down to see which specific Health Rules are failing and which specific CIs are missing required fields

C) Export all Linux server CIs to Excel and manually check for empty fields

D) Activate more Health Rules to increase the score

💡 CMDB Health provides a specific drill-down feature for exactly this purpose.

Answer: B — The CMDB Health dashboard provides drill-down functionality: clicking the 45% Completeness score for cmdb_ci_linux_server shows which specific Health Rules are failing (e.g., "support_group required," "owned_by required") and lists the specific CIs that fail each rule. This targeted view enables efficient remediation without touching CIs that are already compliant. Discovery re-run (A) might help if fields can be auto-populated, but most completeness failures (business fields like owned_by, support_group) require human input, not automation.

2. CMDB Health shows the Staleness dimension for network devices suddenly dropped from 88% to 32% overnight. All other dimensions remain stable. What is the most likely root cause?

A) 70% of network devices were decommissioned overnight

B) A Discovery configuration change (credentials expiration, schedule deletion, or IP range change) broke Discovery for network devices — last_discovered timestamps stopped updating

C) The CMDB Health staleness threshold was accidentally lowered from 90 days to 1 day

D) Network device CIs were reclassified to a different class

💡 Staleness = time since last_discovered update. A sudden drop across an entire class suggests the data source (Discovery) stopped running for that class.

Answer: B — A sudden, class-wide Staleness drop is the signature of a Discovery configuration failure. When Discovery stops running for a category of devices (credential expiration is the most common cause — SNMP community string changed, or SSH key expired), no CIs in that class get their last_discovered timestamp updated. Within a few days, the staleness threshold is breached for all of them simultaneously. Check: did any Discovery schedules change? Did network device credentials expire? Option C is possible but less likely — changing the threshold would affect multiple CI classes, not just network devices.

3. A CMDB Data Manager policy is configured to automatically set operational_status=Retired for any server CI with last_discovered > 60 days. A server CI for a disaster recovery standby that is only powered on during DR tests (every 6 months) is now showing as Retired. What went wrong and what should be done?

A) The policy should be deleted — automatic retirement is never appropriate

B) The DR standby CI's operational_status should be set to DR Standby (4), and the Data Manager policy should be configured to exclude CIs with operational_status=4 from the aging rule

C) The CI should be deleted and recreated manually every 6 months

D) The staleness threshold should be increased to 365 days for all CIs

💡 There's a specific operational_status value for DR standby devices. How should aging policies handle known exceptions?

Answer: B — The DR standby server is correctly not found by Discovery (it's powered off most of the year), but this is expected and known behavior, not a decommission. The correct fix has two parts: (1) Set the CI's operational_status to "DR Standby" (4) to reflect its true state. (2) Modify the Data Manager policy to exclude CIs already in DR Standby status from the 60-day aging rule. DR systems have intentionally different discovery patterns and need explicit exemptions in aging policies. Increasing the threshold for ALL CIs (D) would hide real decommission events for normal servers.

4. An administrator wants to create a custom CMDB Health Rule for the cmdb_ci_business_app class that flags any Business Application record where the business_criticality field is blank. Which Health dimension is most appropriate for this rule?

A) Compliance — the field value violates a format rule

B) Completeness — a required field is missing

C) Staleness — the record hasn't been updated recently

D) Correctness — the data doesn't match an authoritative source

💡 A missing required field is measured by which Health dimension?

Answer: B — Completeness measures whether required fields are populated. A blank business_criticality field means the record is incomplete — missing data that should be present. Compliance (A) would apply if the field had an invalid value (e.g., "Very High" when only 1-4 numeric values are allowed). Staleness (C) measures time since update. Correctness (D) measures accuracy vs. authoritative sources. "Field is empty when it should have a value" = Completeness dimension.

5. A CMDB Manager reports to the CIO that the overall CMDB Health score improved from 58% to 79% over the past quarter. The CIO asks "What does this mean for the business?" What is the most meaningful business-aligned response?

A) "It means we have fewer CIs in the database"

B) "It means our data quality improved from Red to Yellow threshold — CIs now have more complete records, fewer duplicates, and more current data, which should reduce incident MTTR and improve change impact accuracy"

C) "It means our IT team did more database maintenance work this quarter"

D) "It means the CMDB Health tool is now configured more leniently, so the score appears higher"

💡 Connect the metric improvement to the business outcomes it enables.

Answer: B — A CMDB Health score improvement from 58% (Red/Critical) to 79% (Yellow/Caution) means real, measurable improvements: more CIs have complete required fields (fewer incidents routed to wrong teams), fewer duplicates exist (more accurate impact analysis), and more CIs have current data (change risk assessment is more reliable). The business translation: faster incident resolution, fewer failed changes, better IT planning data. This is the kind of language that resonates with the CIO — outcomes, not technical metrics.

Exam Checkpoint

Practice Questions

4 questions · Select an answer to see the explanation immediately.

CMDB Health KPIs & Data Manager Quiz 1 / 4

The CMDB Health Completeness score for Windows servers is 45% (Red). The IP address field is populated on 95% of CIs. The support_group field is populated on only 40%. Which Health dimension is failing, and what is the targeted remediation?

💡 Explanation

B is correct. Completeness measures whether required fields are populated. A field that is blank on 60% of CIs is a Completeness failure. The correct approach: use CMDB Health dashboard drill-down to identify exactly which CIs are missing support_group (not all 2,000 servers — just the ~1,200 that are failing this specific rule). Staleness (A) measures time since last Discovery, not missing field values. Compliance (C) applies when values exist but violate format rules. Correctness (D) applies when values exist but are inaccurate compared to authoritative sources.

CMDB Health KPIs & CMDB Data Manager — Measuring and Managing Data Quality

CMDB Health — The Quality Scorecard

CMDB Health Dimensions

CMDB Health Rules — Configuring What Gets Measured

Out-of-Box Health Rules

Creating a Custom Health Rule

Health Scoring, Thresholds, and Dashboard Navigation

The CMDB Health Dashboard — Key Sections

Staleness — The Time-Dimension of Data Quality

How Staleness Is Calculated

Stale CIs and Decommission Detection

CMDB Data Manager — Bulk CI Lifecycle Management

What CMDB Data Manager Does

Data Manager Policies

CI Lifecycle States — Operational Status Values

CMDB Health as Executive KPIs

CMDB Health KPIs & Data Manager — Key Facts

Term Grid

Practice Questions

Practice Questions