If you write your search to be such a reporting type search that returns events if your condition is true and doesn't if your condition is false, you get what you want.
The search machinery, to use batch mode, has to be able to determine that there is nothing about the search that is going to require fetching the events strictly in time order. If the output of the search is the events themselves, it can't do that. However if you deal with counts, it can do that.
Simply determine the count as part of the search, rather than an alert post-action.
I am interested in examples. We have a number of alerts and where we alert on some threshold of events in the past 5/10/15 minutes.
We noticed that we could transform our alerts into "isBatchMode" alerts to take advantage of batch mode search by adding "| stats count". But it is nice to see the actual events or else information about the events rather than just a count number.
I welcome ideas on ways to convert searches into batch mode search alerts.
The problem with the goal of wanting to see the events while run in batch mode is that the batch mode execution path cannot produce the events in time-order. That would make reviewing the event stream of the search extremely confusing in some cases, and would break our general contract in any event.
That said, there's a useful Enhancement Request in here somewhere, but I'm not sure what it is exactly. Maybe something like "we want the efficiency of batch mode searches for alerting, but .... we want to see the events." I'm not sure if that's "sometimes while troubleshooting, or "in the case the alert actually fires" or what. Basically the interface has to be usable and it has to work out to somehow be cheaper than not running the search in batch mode in the first place.