I came up with a search that shows _indextime almost certainly does not mean "available for search".
The search uses the addinfo command to get the time when the search was executed, then compares that time to the most recent available event's _indextime as well as the most recent event's event time (_time).
Here is the search to tack on to the end of some base search you are interested in:
YOUR_SEARCH_HERE
| eval lag_sec=_indextime-_time |
stats max(lag_sec) as max_lag max(_indextime) as max_index_time max(_time) as max_event_time
| addinfo
| eval index_lag_for_search = info_search_time - max_index_time
| eval event_lag_for_search = info_search_time - max_event_time
| table info_search_time info_min_time info_max_time, max_event_time, max_index_time, max_lag, index_lag_for_search, event_lag_for_search
For the timeframe, set it to be small and recent, earliest = -1m and latest = now, so you are sure to get the most recent event data available. The base search should be against a high frequency data source (in my case the events are written at least once per second to the index involved).
For my base search, I found that the maximum indexing lag never exceeds 2-3 seconds for any of the events in the index, but the "event_lag_for_search" measurement, which shows the most recent event available for the search can sometimes fall behind by 30+ seconds.
@gsumner , it seems like this can help answer at least one of your questions:
Is it when the first searchable copy is written? NO, _indextime does not seem to mean that the event is searchable/available for search
... View more