1.1 CMDB Health Dashboard and the Three Cs

CMDB Health Dashboard and the Three Cs

In ServiceNow, configuration governance is centered around the CMDB Health Dashboard. This dashboard serves as the central control panel for monitoring the quality and reliability of configuration data across the enterprise. Maintaining a healthy CMDB is a critical prerequisite for successful ITOM (IT Operations Management) implementations, including automated Discovery, Service Mapping, and event management. A polluted or neglected CMDB leads to failed change evaluations, prolonged incident resolution times (MTTR), and inaccurate business impact analysis.

The CMDB Health Dashboard evaluates configuration items (CIs) against three Key Performance Indicators (KPIs), commonly referred to as the Three Cs:

1. Completeness
2. Compliance
3. Correctness

Each of these KPIs is evaluated using scheduled background jobs that scan the CMDB, assess records against active rules, and populate the metric results tables.

---

1. Completeness KPI

The Completeness scorecard measures the density of your CI data. It answers the question: Are the essential attributes of my configuration items populated? Without complete data, IT service desk agents, change managers, and automated routing flows cannot make informed operational decisions.

Completeness is broken down into two sub-metrics:

• Mandatory Attributes: Critical fields that must be populated for a CI to be considered usable. If a mandatory attribute is missing, the CI is flagged as incomplete and a health result is generated.
• Recommended Attributes: Fields that are highly beneficial for operational workflows but not strictly required for the CI to exist in the database (e.g., Asset Tag, Support Group, or Cost Center).

Administrators configure Completeness rules within the CI Class Manager. In the Class Manager, you can define which attributes are mandatory or recommended for any specific CI class in the hierarchy. Rules are inherited by default, meaning a rule defined on the base Configuration Item (cmdb_ci) table will apply to all child classes (such as Computer, Server, or Database) unless explicitly overridden at a lower level.

Common Completeness Attributes by Class

The scheduled job CMDB Health Dashboard - Completeness runs nightly by default to scan the CIs, calculate completeness scores, and write results to the CMDB Health tables.

---

2. Compliance KPI

The Compliance scorecard measures configuration drift and adherence to organizational standards. It answers the question: Do my configuration items comply with certified templates, desired states, and audit requirements?

Compliance is calculated using three main mechanisms:

• Desired State Audits: Administrators create desired state templates that define the expected values for specific fields on a CI. The compliance engine compares the actual values discovered on the CI against these templates. Any variance is flagged as a drift.
• Certification Filters: Used in the Data Certification application, these filters identify CIs that need manual verification by their owners. For example, a filter might require database owners to certify their databases quarterly, validating ownership and location.
• Audit Results: The outcomes of scheduled compliance audits. If an audit script detects unauthorized changes or deviations from regulatory benchmarks (such as CIS controls), the CI is marked non-compliant.

By default, the scheduled job CMDB Health Dashboard - Compliance evaluates compliance. Compliance audits can also be triggered on-demand or as part of a continuous integration pipeline.

---

3. Correctness KPI

The Correctness scorecard evaluates data integrity and cleanliness. It answers the question: Is my CMDB clean and free of duplicate, stale, or orphaned records? This KPI is often the most critical for Discovery implementations, as duplicate CIs directly degrade the accuracy of identification rules.

Correctness is measured using three sub-metrics:

• Duplicate CIs: Multiple records representing the same physical device or service. The Identification and Reconciliation Engine (IRE) flags duplicates when incoming payloads match existing records on specific identifiers but have different system IDs.
• Orphaned CIs: Records that lack required relationships or parents. For instance, an Application CI that has no relationship to a host computer, or a Network Interface CI with no parent network adapter.
• Stale CIs: CIs that have not been updated or discovered for a long time. By default, staleness rules flag CIs after 60 days of inactivity (no updates to the sys_updated_on field or discovery source fields).

Configuring Staleness Rules

Staleness thresholds can be adjusted per CI class using the CI Class Manager. While the default is 60 days, dynamic cloud environments (like AWS EC2 or Kubernetes pods) may require much shorter staleness rules (e.g., 7 to 15 days), while legacy mainframe systems might use a 90-day threshold.

---

4. Scorecard Roll-Up and Metric Weighting

The scores calculated for each CI are aggregated and rolled up to compute class-level scores, which then roll up to the overall CMDB Health Score. These results are stored in the reconciliation_metric_result and cmdb_health_result tables.

Administrators have the authority to customize the weighting of each KPI. In the CMDB Health Dashboard Properties, weightings can be adjusted on a scale of 0 to 10 (where 0 excludes the metric entirely from calculations). For example, a organization focusing heavily on data hygiene might set Correctness weight to 10, Completeness to 7, and Compliance to 5.

By scheduling these dashboard jobs to run regularly, platform owners can isolate weak points in data ingestion, identify issues with specific discovery sources, and assign remediation tasks to CI owners to ensure continuous CMDB health.