ServiceNow's CMDB health dashboard scores the configuration management database (CMDB) on three metrics: completeness, correctness and compliance. The score is only as meaningful as the rules behind it. A dashboard left at its default settings can show green while change teams, incident teams and auditors all distrust the data, because it measures what it was told to measure, across the classes it was told to include. Making it useful means configuring each metric deliberately, checking the jobs behind it, and adding measures that reflect what the consuming processes actually feel.
What the three health metrics measure
| Metric | What it checks | What drives it |
|---|---|---|
| Completeness | Whether required and recommended attributes are populated | The fields you mark as required or recommended per class |
| Correctness | Duplicates, orphan CIs and stale CIs | Identification, orphan rules and staleness rules per class |
| Compliance | Whether CIs match the expected values in audits | The audits and templates you define |
Each metric rolls up into class scores and an overall score. Our article on the three Cs of a CMDB covers what each one means in practice. This article covers how to configure the dashboard so the numbers can be trusted.
Why a green dashboard can be wrong
We regularly see healthy scores on CMDBs that the organisation doesn't trust. The same causes come up.
- The jobs aren't running. Health scores are calculated by scheduled jobs. If they've failed or been deactivated, the dashboard shows an old result.
- Few classes are in scope. Only classes with health rules are scored. A score across three well-kept classes says nothing about the rest.
- Completeness checks the wrong fields. If the required fields don't include support group, criticality or life cycle, the score ignores what change and incident need.
- Presence is mistaken for accuracy. A populated field counts as complete even when the value is wrong.
- No compliance audits exist. With no audits defined, compliance tells you very little.
Configuring each metric deliberately
Completeness. For each class in scope, set required and recommended fields from what the consuming processes need, agreed with their owners. Support group, owner, life cycle stage and status, and environment are strong candidates on most operational classes.
Correctness. Set staleness rules per class, based on how often each class is really updated. A server discovered daily can be stale after a week. A class maintained by hand needs a longer period. Set orphan rules so operational CIs without the relationships they should have are flagged. Duplicates depend on identification rules, so our identification rules article is the place to start.
Compliance. Define audits that check the values that matter to governance, such as in-scope services having an owner, or production servers carrying the right support group. Link failures to remediation tasks with owners.
Review thresholds and weights with the process owners, so the colours reflect what they consider acceptable.
Adding the measures the dashboard doesn't show
The built-in metrics describe the data. They don't show its effect. Add a small set of outcome key performance indicators (KPIs) alongside them.
- failed changes where configuration data was a contributing cause
- incidents resolved without a configuration item (CI), and CI accuracy from a monthly sample
- vulnerability detections that couldn't be matched to a CI
- open de-duplication tasks, and the age of the oldest
- CI counts per source compared with each source's own inventory
When the health score and the outcome figures disagree, trust the outcome figures and investigate the rules.
Running the dashboard as a management tool
A dashboard nobody reviews doesn't improve anything.
Check the health jobs after every platform upgrade. Review class scores monthly with the configuration management team and quarterly with process owners. Route every failed rule to a named owner as a task, and track task age.
Record in the RACI (responsible, accountable, consulted, informed) who owns the health rules for each class, and who acts on the results. Put changes to rules, thresholds and weights through change management, so a score can't be improved by quietly relaxing the rules.
For what a full assessment involves beyond the dashboard, see our article on the CMDB health assessment.
How Apex helps
Our two-week CMDB health baseline scores which CIs are trustworthy and which are guesses, independently of your dashboard settings. It shows where your health rules are measuring the wrong things, and gives you a scored report you can take to your change advisory board.
Our data quality assessment then sets weighted critical success factors, key performance indicators and metrics you can build into the dashboard. We scope it with you at an initial consultation.
Book a CMDB diagnostic call or arrange a meeting with a consultant.
Frequently asked questions
What are the three metrics of CMDB health?
Completeness, correctness and compliance. Completeness checks populated attributes, correctness checks duplicates, orphans and staleness, and compliance checks CIs against audits.
Why hasn't our health score changed in weeks?
Check the scheduled health jobs first. A failed or inactive job leaves the dashboard showing an old result.
How should staleness periods be set?
Per class, based on how often each class is genuinely updated by discovery or other sources.
Can the dashboard show whether data is accurate?
Partly. Compliance audits check values against expectations. Accuracy sampling and outcome measures fill the rest.
Written by Iain Moone, Apex Configuration Group.
CMDB Health Assessment: What It Involves And What It Risks
Bad CMDB Data Leads To False Patch Compliance
