Event Management event reaches Processed state with empty Alert field after em_alert table cleanup - Support and Troubleshooting

Event Management event reaches Processed state with empty Alert field after em_alert table cleanup .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: ; } } Issue An Event Management event reaches the Processed state with the alert field empty, even though the event qualifies for an Alert (for example, ticketFlag=1 , and no matching Ignore rule). The Processing Notes contain a reference to an Alert sys_id, but that sys_id no longer exists in em_alert .

Symptoms The event state is Processed. The event alert field is empty. The event has ticketFlag=1 in additional_info and is not matched by an Ignore-type event rule. Event Processing Notes contain a line such as: Alert is already bound to CI with id: . Looking up that sys_id in em_alert returns no record. Re-processing the event (set state=Ready , clear Processing Notes, and save) successfully creates a new Alert with the same message_key . Affected events span multiple sources and resources, and can be only hours old at the time of investigation. Environment Event Management em_alert table with an active sys_auto_flush (table cleanup) rule Auditing disabled on the cleanup rule (common configuration) Cause The event correctly bound to a pre-existing Alert through message_key , but that Alert was subsequently deleted by a sys_auto_flush (table cleanup) rule on the em_alert table before the lookup could resolve. The event therefore references an Alert sys_id that no longer exists, which leaves the alert field empty.

Two commonly observed cleanup ages on em_alert are:

604800 seconds (7 days) 7776000 seconds (90 days) When the cleanup rule has auditing disabled, no audit trail of the deletion is retained, which makes the cause difficult to identify from the event record alone. You can still confirm the deletion from system logs and from the corresponding em_alert_history INSERT.

Note: A recently arrived event can encounter this issue when its message_key matches an older Alert that has already exceeded the cleanup age. Event age alone does not rule out cleanup as the root cause — Alert age does.

Resolution From the affected event's Processing Notes, capture the Alert sys_id referenced in the message: Alert is already bound to CI with id: . Query em_alert for that sys_id. If no row is returned, query em_alert_history for the same sys_id to confirm that the Alert had previously been created. Open the em_alert cleanup configuration list at https:// .service-now.com/sys_auto_flush_list.do?sysparm_query=tablename=em_alert . Note any active rules and their age-in-seconds values. Review system logs (or equivalent node logs available through Now Support) for the window around the event's processing time, and confirm that an INSERT INTO em_alert_history for the Alert sys_id is present while the live em_alert row is gone. Contact the team or change owner that created the cleanup rule to confirm business intent. Adjust the retention age, add scoping conditions, or turn off the rule if retention is too short for operational needs. For more information, see the Data Retention Period for Alert and Event Tables [KB1709192] and Rotate event tables and alert table cleanup [KB1845291] articles in the Now Support Knowledge Base. To restore an Alert for an already-impacted event as an immediate workaround, set the event state to Ready , clear the Processing Notes, and save. The event re-processes and creates a new Alert with a new sys_id. Downstream reporting joined on the original Alert sys_id is not retroactively repaired. After cleanup retention is adjusted, monitor for recurrence over the new retention window. Related KB articles Data Retention Period for Alert and Event Tables [KB1709192] Rotate event tables and alert table cleanup [KB1845291] How to manage data retention, table rotation, and instance size [KB0780216] Alert Processing Explained [KB0756521]