Troubleshooting ServiceNow CMDB: A Practical Guide

A CMDB fault is a gap between what the configuration record says and what is actually running, and the usual cause is a source or rule that keeps writing the wrong value. This guide takes the common symptoms in turn, from missing items and duplicates to stale records and failed imports, with the likely source and the fix for each.

Discovery Not Finding Expected Configuration Items

Symptom: Discovery scan runs, but expected servers or applications are missing from CMDB. Root causes: Discovery credentials are expired or insufficient, the server is not reachable over the network, or Discovery scanner is not configured to scan that infrastructure.

Diagnosis: First, verify Discovery is running. Check Discovery execution logs: Did the scan complete successfully? Were there credential errors or network timeouts? Verify the Discovery source is correctly configured: Does it have the right target range or endpoint? Does it have permission to scan that infrastructure?

Test connectivity: From the MID Server running Discovery, can you reach the target system? Ping the target IP, or connect to the API endpoint manually. If connectivity fails, the issue is network or firewall; coordinate with network team to enable connectivity. If connectivity works but Discovery is still missing items, increase Discovery verbosity and check detailed logs for scanning errors.

Fix: Update Discovery credentials if they are expired. Verify Discovery source configuration is complete. If a server requires agent-based discovery (not network-based), ensure the Discovery agent is installed and communicating. Add missing servers manually to CMDB and mark them as needing reconciliation.

CMDB Duplicate and Orphaned Records

Symptom: CMDB contains duplicate records for the same server (two records for “WebServer1”) or orphaned records (servers that are deleted but CMDB records remain). Duplicates cause incorrect relationships and confuse automation. Root causes: Discovery created records independently without deduplication, or records were manually created without checking for existing records.

Diagnosis: Query CMDB for potential duplicates: servers with similar names, overlapping IP addresses, or the same serial numbers. Review records to determine if they represent the same server or different servers. Check deletion logs to find when servers were deleted in reality but when CMDB records were last updated.

Fix: Merge duplicate records in CMDB: keep one record and transfer relationships to it, then delete the duplicate. For orphaned records, confirm the server is no longer in use (not in Discovery, not in active inventory systems), then delete or mark as decommissioned. Implement deduplication logic in Discovery scans to prevent future duplicates.

Relationship Integrity Issues and Missing Dependencies

Symptom: Service maps show incomplete dependencies; an application is not linked to its database despite the relationship existing in reality. Impact analysis is therefore unreliable. Root causes: relationships were not created during initial load, relationships were deleted or modified incorrectly, or the third-party system creating relationships (CI import, integration) failed.

Diagnosis: Query relationships for the affected configuration item. For example, query all relationships to a database server to see which applications are linked to it. Compare against documentation or interviews with system owners. Identify missing relationships. Check integration logs if relationships are created by an import process; look for errors.

Fix: Manually create missing relationships in CMDB. If relationships are created through an import process that is broken, fix the import logic or mapping, then re-run the import. Validate that relationships are now complete by running Service Mapping and verifying the topology is correct.

Stale CMDB Data and Out-of-Sync Records

Symptom: CMDB shows a server running an older OS version, but the actual server runs a current OS version. Infrastructure has been updated, but CMDB was not. Root causes: no ongoing reconciliation process, system owners are not updating CMDB when they make changes, or Discovery is not running frequently enough.

Diagnosis: Run a targeted Discovery scan on the affected system and compare new scan results against CMDB records. Identify field differences. Check when CMDB records were last modified; if no recent updates, CMDB is likely stale. Interview system owners: When was the change made? Why was CMDB not updated?

Fix: Update CMDB records with current data from Discovery. Schedule more frequent Discovery scans (weekly or continuously for volatile systems). Improve governance: send periodic reminders to system owners requesting updates, or implement self-service CMDB forms where owners can quickly update key fields (OS version, owner, status). Consider automated updates: if Discovery provides authoritative data, automatically update CMDB without manual approval.

Reconciliation Process Not Detecting Discrepancies

Symptom: A server is decommissioned and removed from production, but it remains in CMDB for months without anyone noticing. The reconciliation process is not catching this discrepancy. Root causes: Reconciliation is not running, reconciliation is running but is not comprehensive (not checking all configuration items), or discrepancies are detected but not followed up.

Diagnosis: Verify reconciliation is scheduled and running. Check reconciliation logs: Are discrepancies being detected? Are they being logged? Review discrepancy reports: What is the volume of detected discrepancies? What is the resolution rate?

If reconciliation is not running, re-enable it and ensure MID Server has connectivity to perform scans. If running but not detecting discrepancies, expand reconciliation scope: reconcile more configuration item types, increase scan frequency, or improve reconciliation rules to catch more edge cases. If discrepancies are being detected but not resolved, assign clear ownership and follow-up responsibilities.

Fix: Establish a reconciliation cadence (weekly or monthly). Assign a team to review and resolve discrepancies. For decommissioned servers, provide a workflow for marking them as end-of-life in CMDB. Track discrepancy resolution time and escalate if it exceeds targets.

CMDB Import and Integration Failures

Symptom: A CMDB import from an external source (asset management system, cloud provider billing) is failing, so configuration items are not being synced. Root causes: Import credentials have expired, the source system API has changed, data format mismatch, or the integration is not running.

Diagnosis: Check integration logs for error messages. Look for authentication errors (expired credentials), API errors (endpoint not found), or data validation errors (field format mismatch). Verify the import is scheduled and running. Test the import manually: trigger it on-demand and check results.

Fix: Update credentials if they are expired. If the source API has changed, update the integration mapping. If data format is wrong, work with the source system team to understand the new format, then update CMDB import mappings. Test with a small subset before running full import.

Symptoms this section covers and where they often start

The problems below appear once the CMDB is in use, and they are easy to misdiagnose because the data looks plausible on screen. Start with the symptom, then work through the source it points to often.

A short diagnostic order

1. List every source that has written to that record, using the record’s update history rather than memory.
2. Decide whether the record is wrong, the source is wrong, or the question was asked of the wrong view.
3. Fix the cause at the source where possible. Correcting the record alone lets the same error return on the next run.
4. Re-run the original query or scan and compare the result with the expected answer you wrote in step one.

When a fix makes things worse

Tightening a discovery rule can remove items that a service still relies on, so widen the test before you narrow the rule in production. Changing a relationship type can change impact results for every service that shares the item, so check the affected services first. The service impact analysis guidance covers how service relationships shape impact results. If an automated correction is rolled back, confirm that the rollback also restores the relationships it touched, not only the item fields.

Questions to settle before escalating

How do we know a source is the real origin of a bad value?

Look at the record’s history for the first write that carries the wrong value, and check which source was running at that time. If two sources wrote close together, check both before assigning blame.

Should we disable a feed while we investigate?

Only if the feed is clearly the origin and disabling it does not leave a critical service without updates. Pausing a feed can make the next run look like a large change, so note the pause in the decision log. The common CMDB mistakes page lists patterns that often sit behind a recurring symptom.

Why does a symptom come back after we fixed it once?

Often because the fix changed the record but not the rule that produced the record. Find the rule, whether it is an identity match, a mapping or a scheduled import, and change that. A second fix on the record can last only until the next run.

Is it safe to run these checks in production?

Read-only checks such as viewing record history, comparing a query result and reviewing a job log are safe at any time. Anything that writes, merges or deletes should be tested on a copy first and carried out under the change process the platform team already uses.

Next step

Bring the record identifier, the source list and the expected answer, which can make a diagnosis quicker.

Related guides: ServiceNow CMDB Remediation: Move Findings to Verified Fixes.

ServiceNow CMDB troubleshooting tables, fields and names to check first

When a CMDB record is wrong, start by finding which source last wrote it. Each configuration item carries a discovery source and a last discovered value, relationships sit in their own table, and Discovery runs are logged separately, so most faults can be traced by reading those places before any rule is changed.

These are common out-of-box names. Check them on your own instance and release, because labels, defaults and available fields change between releases.

The Identification and Reconciliation Engine, usually shortened to IRE, sits behind most of these symptoms. It decides whether an incoming record matches an existing item and which source may overwrite which attribute.

Example (hypothetical): a decommissioned server keeps coming back after it is deleted. Read the record’s discovery source and compare its last discovered date with the deletion date. If it is later, a scan or import still lists the host, so the fix is at that source.

Which table shows how two configuration items are related?

Relationships are rows in cmdb_rel_ci, each with a parent, a child and a relationship type. Filter on the affected item as parent or child; a missing dependency is often a missing row or a wrong type.

How can I tell whether a Discovery run actually touched a record?

Compare the record’s last discovered value with the run history in discovery_status. If the record was not updated after a run that should have covered it, look at the MID Server messages in ecc_queue for probes that were sent and never answered, which often points to credentials or network reach.

What is the Identification and Reconciliation Engine for?

It stops two sources from creating two records for one real item, and it controls which source may change which attribute. When duplicates or flip-flopping values appear, review the identification rules and source precedence first. See CMDB reconciliation and duplicate control.

For wider context read the CMDB guides, the Discovery guides and the notes on the MID Server.