CMDB Relationship Health Dashboard Orphan relationships error

MáteÁ
Tera Contributor

The "Orphan Relationships" report on the CMDB Relationship Health Dashboard shows "Failure threshold reached," even though the metric is set to the maximum available value. I also created "glide.cmdb.health.max_failure_threshold" and set it to a high number, as advised in https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1718966, but that didn't help either. There are currently 33 cmdb_health_orphan_rules in the system. I don't think they are too broad, so I'm really out of options as to why this report is not working. Do you have any suggestions on how to solve this?

1 ACCEPTED SOLUTION

AJ-TechTrek
Giga Sage
Giga Sage

Hi @MáteÁ ,

 

As per my understanding to troubleshoot and resolve the “Failure threshold reached” issue for the Orphan Relationships report in the CMDB Relationship Health Dashboard, even when the metric and glide.cmdb.health.max_failure_threshold are set high.

 

Root Cause Possibilities
1. Metric-level Failure Threshold override
* The value in the Health Metric record (Orphan Relationships) can still cause the failure if the calculated count exceeds the threshold, even if the system property is higher.
* If the Failure Threshold field is set to a number smaller than your actual orphan count, the dashboard will still fail.


2. Metric definition using cmdb_health_orphan_rule
* If one or more orphan rules are too broad or returning a huge dataset, the calculated metric count may hit internal system limits during calculation, causing the “failure threshold reached” status before even applying your configured threshold.


3. System property not applied immediately
* The property glide.cmdb.health.max_failure_threshold may require:
* Cache flush (System Diagnostics → Cache → Flush Cache)
* Recalculation of the CMDB health metrics to take effect.


4. Background job timeout or query limit
* If CMDB Health jobs take too long (millions of orphan relationships), the script may time out and throw the threshold reached flag — unrelated to your configured number.

 

Solution Steps which might helps to resolve your issue -


1. Verify your actual orphan count
* Go to CMDB Health → Relationship Health → Orphan Relationships
* Click into the rule and run it directly to see the number of results.
* If the number is extremely large, it’s not about the property — you need to refine the rule.


2. Adjust or break down the cmdb_health_orphan_rule entries
* Split overly broad rules into smaller, class-specific rules.
* Example: Instead of one rule for cmdb_ci, create separate rules for cmdb_ci_server, cmdb_ci_network, etc.


3. Increase the Failure Threshold in the Metric record
* You currently have 2147483647 (max signed 32-bit int).
* If this matches or is exceeded by actual count, the system will still fail — so you may need to reduce the count by refining rules rather than just increasing numbers.


4. Ensure the system property is active
* Confirm glide.cmdb.health.max_failure_threshold is set globally (Application = Global).
* After updating, Flush Cache and run the scheduled job:
* CMDB Health → Scheduled Jobs → CMDB Health Job – Relationship Health
* Or run com.snc.cmdb_health.job.relationship_health in Scripts - Background.


5. Check for instance query limits
* If your orphan relationship query is returning tens of millions of rows, it will trigger Failure threshold reached even if your limit is high, because of performance safeguards.
* In this case, refining the rules to bring down count is the only option.

 

Best Practice to Fix Permanently as per my experience -


* Review each of the 33 orphan rules and:
* Remove unused rules.
* Narrow filters to match only relevant CI classes.
* Avoid overly generic relationships like cmdb_rel_ci with no filters.
* After adjustments, re-run the Relationship Health job.

 

Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
 

Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025

View solution in original post

2 REPLIES 2

AJ-TechTrek
Giga Sage
Giga Sage

Hi @MáteÁ ,

 

As per my understanding to troubleshoot and resolve the “Failure threshold reached” issue for the Orphan Relationships report in the CMDB Relationship Health Dashboard, even when the metric and glide.cmdb.health.max_failure_threshold are set high.

 

Root Cause Possibilities
1. Metric-level Failure Threshold override
* The value in the Health Metric record (Orphan Relationships) can still cause the failure if the calculated count exceeds the threshold, even if the system property is higher.
* If the Failure Threshold field is set to a number smaller than your actual orphan count, the dashboard will still fail.


2. Metric definition using cmdb_health_orphan_rule
* If one or more orphan rules are too broad or returning a huge dataset, the calculated metric count may hit internal system limits during calculation, causing the “failure threshold reached” status before even applying your configured threshold.


3. System property not applied immediately
* The property glide.cmdb.health.max_failure_threshold may require:
* Cache flush (System Diagnostics → Cache → Flush Cache)
* Recalculation of the CMDB health metrics to take effect.


4. Background job timeout or query limit
* If CMDB Health jobs take too long (millions of orphan relationships), the script may time out and throw the threshold reached flag — unrelated to your configured number.

 

Solution Steps which might helps to resolve your issue -


1. Verify your actual orphan count
* Go to CMDB Health → Relationship Health → Orphan Relationships
* Click into the rule and run it directly to see the number of results.
* If the number is extremely large, it’s not about the property — you need to refine the rule.


2. Adjust or break down the cmdb_health_orphan_rule entries
* Split overly broad rules into smaller, class-specific rules.
* Example: Instead of one rule for cmdb_ci, create separate rules for cmdb_ci_server, cmdb_ci_network, etc.


3. Increase the Failure Threshold in the Metric record
* You currently have 2147483647 (max signed 32-bit int).
* If this matches or is exceeded by actual count, the system will still fail — so you may need to reduce the count by refining rules rather than just increasing numbers.


4. Ensure the system property is active
* Confirm glide.cmdb.health.max_failure_threshold is set globally (Application = Global).
* After updating, Flush Cache and run the scheduled job:
* CMDB Health → Scheduled Jobs → CMDB Health Job – Relationship Health
* Or run com.snc.cmdb_health.job.relationship_health in Scripts - Background.


5. Check for instance query limits
* If your orphan relationship query is returning tens of millions of rows, it will trigger Failure threshold reached even if your limit is high, because of performance safeguards.
* In this case, refining the rules to bring down count is the only option.

 

Best Practice to Fix Permanently as per my experience -


* Review each of the 33 orphan rules and:
* Remove unused rules.
* Narrow filters to match only relevant CI classes.
* Avoid overly generic relationships like cmdb_rel_ci with no filters.
* After adjustments, re-run the Relationship Health job.

 

Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
 

Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025

Cindy Trieu
ServiceNow Employee
ServiceNow Employee

Hi MáteÁ,

 

If you check your cmdb_health_metric_status, are all the metrics marked as Complete, or are there still some processing? If there's still some processing going on, then it won't be updated with the new scores until it's done.