@gcusello's answer should give you the desired output.  Is it possible that some events come out of order?  You can use sort to make sure events are in perfect revere time order.   | sort - _time | transaction Item startswith="Result=fail" endswith="Result=success" | eval EndTime = _time + duration | fieldformat EndTime = strftime(EndTime, "%F %T") | fieldformat duration = tostring(duration, "duration") | fields Item _time EndTime duration   Here you can rename _time as StartTime if you wish, then format it for display.  For large number of events, sort can be expensive.  This is one of the costs of transaction when raw events are not perfectly in order. Here is an emulation you can play with and compare with raw data   | makeresults | eval data = split("02:00:00 Item=A Result=success 02:00:05 Item=B Result=success 02:05:00 Item=A Result=fail 02:05:05 Item=B Result=success 02:10:00 Item=A Result=fail 02:10:05 Item=B Result=success 02:15:00 Item=A Result=success 02:15:05 Item=B Result=fail 02:20:00 Item=A Result=success 02:20:05 Item=B Result=fail 02:25:00 Item=A Result=success 02:25:05 Item=B Result=success 02:30:00 Item=A Result=success 02:30:05 Item=B Result=success 02:35:00 Item=A Result=success 02:35:05 Item=B Result=success 02:40:00 Item=A Result=success 02:40:05 Item=B Result=fail 02:45:00 Item=A Result=success 02:45:05 Item=B Result=success 02:50:00 Item=A Result=success 02:50:05 Item=B Result=success 02:55:00 Item=A Result=success 02:55:05 Item=B Result=success", " ") | mvexpand data | rename data as _raw | rex "^(?<_time>\S+)" | eval _time = strptime(_time, "%H:%M:%S") | extract ``` data emulation above ```   Combining the two, I get Item _time EndTime duration _raw B 2023-11-13 02:40:05 2023-11-13 02:45:05 00:05:00 02:40:05 Item=B Result=fail 02:45:05 Item=B Result=success B 2023-11-13 02:20:05 2023-11-13 02:25:05 00:05:00 02:20:05 Item=B Result=fail 02:25:05 Item=B Result=success B 2023-11-13 02:15:05 2023-11-13 02:30:05 00:15:00 02:15:05 Item=B Result=fail 02:30:05 Item=B Result=success A 2023-11-13 02:10:00 2023-11-13 02:15:00 00:05:00 02:10:00 Item=A Result=fail 02:15:00 Item=A Result=success A 2023-11-13 02:05:00 2023-11-13 02:20:00 00:15:00 02:05:00 Item=A Result=fail 02:20:00 Item=A Result=success

Hello @Aditya Kumar.Maddala, Please check out AppD Docs site for PHP Supported Environments.  https://docs.appdynamics.com/appd/22.x/latest/en/application-monitoring/install-app-server-agents/php-agent/php-supported-environments

You haven't provided sufficient information for anyone to be able to determine why your search picked up events which you weren't expecting, or why you search failed to exclude these from your alert. It is like me asking you, why did my search fail?

thanks for your answer even if it's not really easy to understand the data are approximatively indexed every 20 minutes so concerning my problem i dont understand why my last related event vs my alert happened last Friday and why my alert has occurend once again today

Alerts have throttles but that's at the alert level, not at the event which have been looked at. As I said, it depends on your search and your data. For example, if you are searching over 25 hours, every 24 hours, there will be an overlap of 1 hour. Having said that, it depends how quickly your data is indexed, real lag, and how far behind your timestamp field (_time) is to actual time, extended lag. In order to fashion a search which takes these factors into account, you need to understand your data, how it is indexed, when it is indexed, etc. When you know this, you might have a chance at eliminating events which you have (or may have) already looked at. Another way you might approach this is to copy the events you have looked at into a summary index and then ignore any events which are already in your summary index.

Hello, Thanks for your correction and your help. So this is what I am looking for:    | where (isnotnull(vuln) AND isnotnull(score) AND len(company)>0)) OR (isnotnull(vuln)) OR len(company>0)  Any idea why * didn't work? It seems like "where" is faster than "search"  Thank you

Not so easy, because you have said your lookup contains wildcards, you could append the list of sources from your lookup and count the occurrences, but you might get false positives/negatives where you found a source which matched the wildcard | append [| inputlookup pvs_source_list | table source] | stats count by source | where count < 2