I don't think summary indexing itself is removing the duplicate events here. From what I understand, the summary index is storing the result of the scheduled search. Since the search ends with: | stats count it will return one result row with the total count. So result_count=1 in the scheduler log only means one result row was produced. It doesn't mean that only one event was processed. Also, stats count does not remove duplicate events. If all 311 events were available and matched the search when the scheduled search ran, I would expect the count to be 311. So the part I would check next is whether those 311 events were actually searchable at the time the scheduled search ran. For example, some of them may have arrived late or been indexed after the scheduled search had already completed. It may be useful to compare the scheduled search time range with the _time and _indextime of those 311 events. That should help confirm whether this is a late-arriving data or search-time-window issue. So my understanding is that summary indexing is not automatically changing 311 events into 9 or removing identical messages from the same host. The difference is more likely related to what events were available to the scheduled search when it ran. ... View more