Why does CMDB data become stale even after a cleanup?

Scope

Use this approach when a configuration database supports incident response, change risk, security exposure, software ownership, cost allocation, or compliance. The relevant unit is not “the CMDB” as a whole; it is a fact used by a specific decision under a time constraint.

Why it happens

A cleanup project corrects today’s records but leaves the production mechanism unchanged. Cloud resources appear and disappear, software is deployed outside known pipelines, services change owners, and business relationships evolve. Discovery tools observe different surfaces at different times. Reconciliation rules pick a winner but may erase the disagreement that operators need to see.

Staleness is also semantic. A server may still exist while its application relationship, support group, criticality, or data classification is wrong. A single last-updated timestamp cannot describe the freshness of every attribute.

Diagnosis

Start from a failed or risky decision, not from the table count:

1. Which configuration fact was used or missing?
2. What real-world event should have changed it?
3. Which source could observe that event, and when?
4. How was the entity identified across sources?
5. Did reconciliation preserve conflict, provenance, and observation time?
6. Who owned the attribute and the exception?
7. What should the consumer have done after the freshness budget expired?

Repeat across incident, change, security, and cost use cases. Different facts will need different sources and freshness targets.

Solution

Define an evidence contract for each decision-critical attribute. Name the authoritative or corroborating sources, stable identity keys, observed time, effective time, confidence, maximum lag, conflict rule, owner, and safe fallback. Represent unknown and disputed states explicitly instead of selecting a convenient value.

Connect lifecycle events to updates: provisioning, deployment, ownership transfer, network change, retirement, contract change, and deletion. Use discovery as one source, not as the entire lifecycle. Test for orphaned relationships, impossible states, identity collisions, expired overrides, and sources that stopped reporting.

Measure freshness at consumption. A record can pass a generic health score and still be too old for a change approval or security response. Make the consumer warn, degrade, require confirmation, or block an action when the relevant fact exceeds its budget.

Close the loop from real incidents and decisions. When a configuration fact fails, classify the mechanism—missing event, identity mismatch, source delay, reconciliation error, ownership gap, or semantic ambiguity—and improve the pipeline rather than only repairing the record.

Artifact

Create one decision-freshness contract per critical fact:

Field	Example question
Decision	Which action depends on this fact?
Attribute	What exact property or relationship is needed?
Identity	How is the entity resolved across sources?
Evidence	Which source observed what, and when?
Freshness budget	How old may the evidence be for this decision?
Conflict behavior	Preserve, escalate, rank, or block?
Owner	Who fixes the source and who accepts exceptions?
Consumer fallback	Warn, degrade, confirm, or deny?

Common mistakes

• Running a one-time cleanup without changing lifecycle events and accountability.
• Using one “last updated” value for attributes with different evidence sources.
• Letting reconciliation discard conflict and provenance.
• Measuring population completeness while ignoring decision-critical relationships.
• Treating manual overrides as permanent truth without expiration.
• Adding discovery sources before solving identity and ownership.