The use of the Splunk transaction command requires a field that ties together the events, like a session_id or device_id, etc. It looks like your events don't have such a unifying field; instead, you want to assume that the time-based ordering of the fields always defines a transaction. We can do that. Assuming you've extracted the messages like "I move from communications-interrupted to normal" and "I move from communications-interrupted to startup" into a field called msg , this should work: your base search collecting the events | sort 0 _time | streamstats earliest(_time) AS start_time reset_after="(msg=\"I move from startup to normal\")" | eval duration=if(msg="I move from startup to normal", _time-start_time, NULL) The events that define the end of a transaction (events with msg="I move from startup to normal" ) will get a field called duration , with the duration (in seconds) of the time between that particular event and the most recent event preceding it that contains msg="I move from normal to communications-interrupted" . All events will also have a field called start_time , which is the value of _time for the most recent event marking the start of the pseudo-transaction. ... View more

I think I'm reading your question differently than the others who've answered. It looks to me like you want to be able to add some options into the time filter dropdown to allow users to search for events by week number. The good news: this is possible. The bad news: I don't think it's possible to do this by adding to the regular timepicker. But if you want a dashboard where the time filters are done in a custom dropdown that allows users to select the week, here's a template for doing that: <form> <label>test_timepicker</label> <fieldset submitButton="false"> <input type="dropdown" token="week_timepicker"> <label>Week</label> <choice value="w1">Week 1</choice> <choice value="w2">Week 2</choice> <choice value="w3">Week 3</choice> <change> <condition label="Week 1"> <set token="time_earliest">@y</set> <set token="time_latest">@y+1w</set> </condition> <condition label="Week 2"> <set token="time_earliest">@y+1w</set> <set token="time_latest">@y+2w</set> </condition> <condition label="Week 3"> <set token="time_earliest">@y+2w</set> <set token="time_latest">@y+3w</set> </condition> </change> </input> </fieldset> <row> <panel> <event> <search> <query>index=_internal</query> <earliest>$time_earliest$</earliest> <latest>$time_latest$</latest> </search> </event> </panel> </row> </form> You can add to this list of options and make it totally custom - some week options, some day options, etc. The key is to add a <choice> relating to the custom time period you want to specify and then add a <condition> element below that sets both tokens $time_earliest$ and $time_latest$ , which are consumed by the panel below running a search. The values you'll use in the <condition> elements will be drawn from this guide: http://docs.splunk.com/Documentation/SplunkCloud/6.6.3/SearchReference/SearchTimeModifiers ... View more

If each row has exactly two values for Time, I'd suggest this: your base search | eval first_time=mvindex(Time, 0), last_time=mvindex(Time, 1) This will create two new fields, each containing one of the values from the Time field. ... View more

I'd approach this by using eventstats before stats, given the data you presented. First, cross-apply the values from field1 and field2: | eventstats values(field1) AS field1 BY field2 This should take your first table and make it look like this: field1 field2 field3 field4 field5 A val1 A B val2 A B val3 C val5 C D val4 C D val6 Now every row in the table has a value for field1 , making it possible to use stats to populate the table: | stats values(field2) AS field2 values(field3) AS field3 values(field4) AS field4 values(field5) AS field5 BY field1 If that doesn't work, it means the table likely has some instances where there is no value for field1, like maybe this: field1 field2 field3 field4 field5 A val1 A B val2 A B val3 C val5 C D val4 C D val6 E val7 E val8 If your data has events like that, I can help you adjust your search. It'll be a little more complex, but it's still doable. ... View more

Based on the discussion from the other answer, I have a suggestion: index=maildata | stats first(stat) AS stat, values(msgid) AS msgid, values(size) AS size, values(from) AS from, values(to) AS to by qid | search stat!="Sent" ... View more

Based on the clarification in the comments, I'm going to refine your requirements: You will have two time periods you are comparing. Sometimes it will be "two weeks ago" vs "one week ago". Sometimes it will be "yesterday" vs "today". In either case, you want the "Difference" table to contain entries where [field1 field2 field3] appears only in the more recent window (e.g. "one week ago" or "today" in the two cases described above) and not in the older window. You do not want it to contain entries where [field1 field2 field3] appears only in the older window. To find the "Difference" table as described, you should run your base search over the last two weeks, thus collecting all events. Then use stats to count similar events and compare their earliest seen time to the earliest date of the more recent window, and finally filter based on the number of times a duplicate event was seen and when it was first seen. In the following example, I will compare events for the last 2 weeks. your base search that collects all events over the last two weeks | stats earliest(_time) AS _time count by field1, field2, field3 | where count=1 AND _time>=relative_time(now(), "-14d@d") | fields - count _time You can use this same approach to find the events for the "Equals" table but this time filter for events | where count>1 and also compare both the earliest seen time and the latest seen time to ensure there was an event int each of the two time windows: your base search that collects all events over the last two weeks | stats earliest(_time) AS earliest_time latest(_time) AS latest_time count by field1, field2, field3 | where count>1 AND earliest_time<=relative_time(now(), "-14d@d") AND latest_time>relative_time(now(), "-14d@d") | fields - count earliest_time latest_time If you want to compare only yesterday and today, you can replace instances of relative_time(now(), "-14d@d") with relative_time(now(), "@d") to specify the breaking point between "yesterday" and "today". ... View more