The purpose of Self Health Monitoring tables in ServiceNow and also is it safe to delete records from these tables?Summary<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } -->The purpose of below tables in ServiceNow and also is it safe to delete records from these tables? Sometimes there can be old mid servers references in these tables that no longer exist and also records that haven't been updated in a long time.cmdb_ci_appl_now_appcmdb_ci_appl_now_app_compcmdb_ci_appl_now_connectorcmdb_ci_appl_now_mid If you are looking to clean up of old records in these tables but are not sure on the impact then see below. -->Self-Health Monitoring is a built-in capability that enables Event Management to monitor its own operational health. When enabled via the evt_mgmt.self_health_active property, it creates dummy Configuration Items (CIs) representing internal components and critical processes, and tracks their health status through scheduled jobs.If the property is set to “alerts only”, the visual map will not be maintained, but alerts will still be generated.When the feature is active, two scheduled jobs are triggered:Insert Health Monitor (hourly):This job invokes the EvtMgmtHealthMapBuilder script, which is responsible for creating and hourly updating a mapped application service called “ServiceNow Event Management”. This service visualizes internal Event Management components and their health status in the Service Operations Workspace.Additionally, this script creates or deletes records in the following CMDB tables as needed:cmdb_ci_appl_now_app_compcmdb_ci_appl_now_appcmdb_ci_appl_now_connectorcmdb_ci_appl_now_midUpdate Health Monitor (every minute):Updates the health status of monitored components and triggers alerts (source: EMSelfMonitoring) if thresholds are breached.The EvtMgmtHealthMapBuilder script dynamically builds the service model using the tables listed above.CI Regeneration Behavior:The scheduled jobs will recreate relevant records in the above tables as needed.Manual deletion is not recommended, especially for records in the connector and MID tables.The system will automatically remove unused or obsolete records.Each CI in the self-health map includes dependency relationships. This allows visibility into each CI's impact on its dependent CIs, which is critical for root cause analysis and service impact assessment.-->To access the self-health application service (map):Navigate to All Menu → search for “Application Service”.Under Event Management, select the “ServiceNow Event Management” record.Click “View Service” to explore the full topology and health indicators. You can also delete records fromcmdb_ci_appl_now_mid and cmdb_ci_appl_now_connector as the relevant records will be repopulated by the above scheduled jobs. -->Please do it with caution (try to delete one record from each table and see the result after executing the scheduled job: Event Management - Insert Health Monitor) , delete the records that don't match the existing records in ecc_agent and em_connector_instance (via the provided background script) below. -->To avoid those deprecated records, a fix was integrated in ZP0, so the client can upgrade or implement the fix manually. In the latter option, the client has to remove this fix from the customer updates table before an upgrade so that it won’t conflict with the new versions of this file in the following upgrades.Attached the updated versions of the 2 BRs that fix this issue (Update self health) for both MIDs and Connectors.Here is a background script to delete the deprecated records:// Step 1: Collect all MID Server display names from ecc_agentvar midNames = [];var eccGr = new GlideRecord('ecc_agent');eccGr.query();while (eccGr.next()) {midNames.push(eccGr.getDisplayValue('name'));} // Step 2: Iterate over cmdb_ci_appl_now_mid and delete records not in midNamesvar cmdbGr = new GlideRecord('cmdb_ci_appl_now_mid');cmdbGr.query();var count = 0;while (cmdbGr.next()) {var displayName = cmdbGr.getDisplayValue('name');if (midNames.indexOf(displayName) === -1) {gs.log('Deleting record: ' + displayName);cmdbGr.deleteRecord();count++;}}gs.info('Deleted ' + count + ' records from cmdb_ci_appl_now_mid not found in ecc_agent.');// Step 3: Collect all connector display names from em_connector_instancevar connectorNames = [];var connectorGr = new GlideRecord('em_connector_instance');connectorGr.query();while (connectorGr.next()) {connectorNames.push(connectorGr.getDisplayValue('name'));}// Step 4: Iterate over cmdb_ci_appl_now_connector and delete records not in connectorNamesvar fakeConnectorGr = new GlideRecord('cmdb_ci_appl_now_connector');fakeConnectorGr.query();var countDeletedFakeConnectors = 0;while (fakeConnectorGr.next()) {var displayNameFakeConnector = fakeConnectorGr.getDisplayValue('name');if (connectorNames.indexOf(displayNameFakeConnector) === -1) {gs.log('Deleting connector record: ' + displayNameFakeConnector);fakeConnectorGr.deleteRecord();countDeletedFakeConnectors++;}}gs.log('Deleted ' + countDeletedFakeConnectors + ' records from cmdb_ci_appl_now_connector not found in em_connector_instance.');