I appreciate your feedback and I'll simply respond with the same commentary I gave another customer regarding a similar case operating on a 10 min interval:
After some testing to verify the saved search mechanics, I have verified that the time snaps of the saved search do not change with delays in the search time execution, and thus the extra work of creating the six searches per hour may not seem necessary (though not harmful either). If a search is scheduled to run at 3:10 and snap to the minute (-10m@m to @m), and it runs at 3:12, the time range of the search will be from 3pm to 3:10pm because it acts as if it was actually run at 3:10 despite the 2 minute delay. That said, having the six searches increases the time period allowed for search kick-off (or completion) delays from 10 minutes to 60 minutes. As we have seen with the user search queue limitations, if a search is delayed past the time of the next scheduled run, it will run the next scheduled run and skip the others.
Also, we should consider the delay of indexed data. If a search runs over the last 10 minutes, it is possible that some of that data has not been received and indexed by the time the search kicks off. Increases the time after the search window helps ensure that all of the data is seen but also increases the delay in seeing the data. The current data delay is between 0-10min (and even infinity for data not indexed prior to the search). If you give 5 min for the latest data in a given period to finish indexing, then the delay in seeing the data is between 5-15min. Thus a search on :00-:10 will run at :15 on the hour. If you want to change the cron to add a slight delay to the search for its search period, you’ll need to consider how much time is acceptable for your team.
Thus while the other approach appears to work fine, this approach allows for longer delays and other potential issues, especially for searches across much smaller time spans where such delays become profoundly more noticable.
... View more