How Long Are Records Retained in the em_event Table?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: ; } } Overview The em_event table uses table rotation to manage event records. Instead of storing all records in a single physical table, records are written to a series of physical shard tables that are rotated on a scheduled basis. Understanding this rotation behavior is important when investigating older events, as a record may no longer be visible from em_event.list even though it has not yet been physically removed from the database. Default em_event Rotation Configuration Out of the box, the em_event table uses seven physical shard tables: em_event0000em_event0001em_event0002em_event0003em_event0004em_event0005em_event0006 By default, a new shard becomes active every day. Event records are written to the shard whose scheduled validity period includes the current time. The rotation definition can be reviewed in the sys_table_rotation table. How to Review the Rotation Schedule The assignment of each shard table can be reviewed in the sys_table_rotation_schedule table. The following fields are particularly useful: FieldDescriptiontable_namePhysical shard table name.valid_fromBeginning of the shard's active period.valid_toEnd of the shard's active period.offlineIndicates whether the shard is currently available through the logical em_event table. Records are written to a shard table only during the period between valid_from and valid_to. When Does a Record Stop Appearing in em_event.list? After the shard's active period ends, the shard remains available for several additional rotation cycles. Approximately four days after the shard's valid_to time, the shard is marked with: offline = true At this point, records stored in that shard are no longer returned when viewing data through the logical em_event table. As a result, the records are no longer visible from: em_event.listList views based on em_eventQueries executed against the logical em_event table This often creates the impression that the records have already been deleted. However, the records may still exist in the underlying physical shard table. Can Records Still Exist After They Disappear from em_event.list? Yes. A record can stop appearing through the logical em_event table before it is physically removed. When a shard becomes offline, records stored in that shard may still exist within the underlying physical table. If the record's URL is already known, it may still be possible to open the record directly while it remains in that physical table. Therefore: A record disappearing from em_event.list does not necessarily mean the record has already been deleted.The logical table view and physical record retention period are not always the same. When Are Records Physically Removed? After a shard has been marked offline=true, it remains in that state until the next rotation cycle. During the following rotation, records stored in that offline shard are removed. As a result, records are generally: Written to an active shard.Visible through em_event.list during the shard's active period.No longer visible through em_event.list after the shard becomes offline.Physically removed during a later rotation cycle. Typical Retention Timeline Using the default configuration, the lifecycle is approximately: Time Since Record CreationStateDay 0Record is created in the active shard.Up to approximately Day 5Record remains visible through em_event.list.Approximately Day 5The shard becomes offline and the record is no longer returned by the logical em_event table.Approximately Day 6The record is physically removed from the underlying shard table. Actual timing may vary slightly because rotation processing is not always completed exactly at the scheduled boundary time. Key Points em_event uses seven physical shard tables by default.One shard is active per day.Records are typically visible through the logical em_event table for approximately five days after creation.Records may continue to exist in the underlying shard table for approximately one additional day after they are no longer visible through em_event.list.Actual retention timing may vary depending on the record creation time and the completion time of the table rotation process.Rotation processing may take additional time after the scheduled rotation boundary.