CMDB Health process tracking and troubleshooting

  • Release version: Zurich
  • Updated July 31, 2025
  • 2 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of CMDB Health process tracking and troubleshooting

    This content provides guidance for ServiceNow customers on tracking and resolving issues with CMDB Health processes in the Zurich release. It covers how to monitor processing status, enable detailed logging, troubleshoot orphan records, and understand failures in CMDB Health metrics and KPIs.

    Show full answer Show less

    Logging and Monitoring

    • By default, only error messages for CMDB Health are logged in the syslog table with the source CmdbHealth.
    • To include info and warning messages (which mark processing cycle start and end), adjust the system property glide.cmdb.logger.usesyslog.CMDBHealth.
    • If scheduled jobs are active but data is missing from the CMDB Health dashboard, check the processing status in the CMDB Health Metric Status [cmdbhealthmetricstatus] table.

    Processing Status and Outcomes

    • All metrics start with the state “In Progress.” Final metric states include:
      • Complete: All classes processed with failures below threshold.
      • Max Failures: Failures hit the threshold; processing aborts and restarts next run.
      • Daily Time Out Pause: Processing time limit reached; paused and resumes next run.
    • KPI final states depend on associated metric states:
      • Complete: All metrics complete and score calculated.
      • Incomplete: Score not calculated due to metric failure threshold reached.
      • Daily Time Out Pause: Timeout due to metric processing time limit.
    • The CMDB Health Processor Status [cmdbhealthprocessorstatus] table tracks progress by class for each metric, with statuses Complete or Draft, enabling identification of classes causing processing delays or validation weaknesses.

    Handling Orphan Records

    • Orphan records occur from broken CMDB hierarchies where some CI records exist only in some tables.
    • Such orphan CIs may not be accessible or deletable via standard UI or GlideRecord and require direct database deletion.
    • ServiceNow Support must be contacted to safely delete these orphan records.
    • Orphan test messages specify which tables contain missing or inconsistent records, guiding cleanup efforts.

    Scripted Audits and Compliance

    • Scripted audits must update their Last ran date field to be included in compliance KPIs.
    • Missing or outdated Last ran date causes CMDB Health to skip audit results, logging an error indicating exclusion from compliance calculations.

    Common CMDB Health Status Messages

    • Failure threshold reached: Dashboard shows this when failing CI counts hit the metric’s failure threshold, causing process interruption.
    • Incomplete score: Dashboard displays this when a metric’s score calculation fails.

    Practical Benefits for ServiceNow Customers

    By using these tracking and troubleshooting methods, customers can:

    • Improve visibility into CMDB Health processing status and failures.
    • Identify problematic classes or validation rules slowing processing.
    • Address orphan records to maintain accurate CMDB hierarchy integrity.
    • Ensure scripted audits contribute correctly to compliance scores.
    • Interpret dashboard status messages to prioritize remediation actions.

    Use the following information to track and resolve issues with the CMDB Health processes.

    Logging

    By default, only error messages are logged to the syslog table, with the source name CmdbHealth. To enable logging of 'info' and 'warning' messages (which are typically logged at the start and end of each processing cycle), update the system property glide.cmdb.logger.use_syslog.CMDBHealth. For information about using this property, see CMDB Health system properties.

    Processing status

    If scheduled jobs are enabled, but data is not displaying on the <ph keyref="var.config-mgmt-database-short"/> dashboard, you can check the processing status in the CMDB Health Metric Status [cmdb_health_metric_status] table. Depending on the status of the inactive metric, decide how to proceed.

    Initially, the state of all metrics is 'In Progress'.

    Possible final states of a metric:
    Complete
    All classes are processed and the number of failures is under the maximum failures threshold.
    Max Failures
    The number of failures for this metric reached the maximum failures threshold. Processing has been aborted and will start over in the next run.
    Daily Time Out Pause
    The processor reached the processing time limit. Processing is paused and will resume in the next run.
    At the end of a processing cycle, the final state of a KPI depends on the final state of its associated metrics. Possible final state of a KPI:
    Complete
    All associated metrics are in Complete state and score calculation is complete.
    Incomplete
    Score is not calculated because one of the associated metrics reached its maximum failure thresholds.
    Daily Time Out Pause
    Timed out because one of the associated metrics has reached its processing time limit.

    Processing time

    If processing of a metric times out, you can find out which class takes too long to process. Use this information to find out if any validation rules are weak.

    The progress of each metric is tracked in the CMDB Health Processor Status table [cmdb_health_processor_status]. Status for classes that have been processed for a metric is Complete, and for classes that are yet to be processed is Draft. By looking at the update time for each class, you can calculate the length of processing time for each class.

    Orphan records due to broken hierarchy

    Orphan rules might detect an orphan CI, which you are not able to access and delete. Or, there might be a mismatch between the list view that displays the orphan records, and the total number of records. These findings are due to records being deleted in the database from only one table in the CMDB hierarchy.

    These CI records are not accessible via GlideRecord and must be deleted directly from the database. Therefore, in this case, to delete an orphan CI from the database you must contact Support to get help.

    Orphan test results provide the details of where exactly the hierarchy is broken. For example, the message "This cmdb_ci_linux_server CI [91054fc24f22520053d6e1d18110c713] is missing record in cmdb_ci_computer table" means that a record of that sys_id must be deleted from the CMDB, cmdb_ci, cmdb_ci_hardware, cmdb_ci_server, and the cmdb_ci_linux_server tables (the Computer class is between the Hardware and the Server classes in the hierarchy.)

    Scripted audits Skipped

    An error message is logged if the results from a scripted audit are not included in the compliance KPI. The reason can be that the script in the audit was not updated to populate its Last ran date field. Without a Last ran date value, CMDB Health is unable to identify these run results as part of a recent complete audit run, and skips those results.