Ah, so you have that part. The HF does not need to be able to see the indexes if the outputs are set up correctly. You can use, at the end of your existing ldapsearch - ... | collect <indexname>  Which should just tuck that data into the index you name there. Again, as long as the index exists on the indexer, your HF doesn't need to "see" the index.  It should "just work".  Which brings up the point that if it doesn't work, I'd suspect your forwarding to your cloud is not actually set up right, but that's a different issue.  🙂 ... View more

I'd love to see a small sample of the data this is based on (and please remember to use the code button to enter it so the browser/system doesn't eat special characters). in any case, 1) your output has Created and Branch, Branch being "alert.message".  Yet you don't include this in your transaction? Here's a run-anywhere search that illustrates the technique.   | makeresults format="CSV" data="time, action, branch 1715258900, create, bigville 1715251900, close, bigville 1715254900, create, smallville 1715253920, close, smallville 1715228900, create, bigville 1715211970, close, bigville" | eval _time = time | transaction maxspan=5h branch    In this case we have two branches, "bigville" and "smallville".  The first 7 lines just build a set of data to work with.  We then convert time into "the real time of the event". The meat is the transaction, we are now doing it "by branch" (though 'transaction' doesn't use the keyword "by".)  So if you run the above - you'll see we create 3 transactions, each has a duration field in it.  (I had to fiddle with the maxspan to get my silly test data to work right). Now, let's add this to the end -   | stats sum(duration) as total_duration by branch   And poof, we now have a total sum of the duration fields for each branch.  Once we have that, we can add to the end...   | eval percent_uptime = (total_duration / (86400*7)) *100   and there's our percent uptime.  Obviously smallville has some problems.  🙂 So, untested (I don't have your data), but I think this should work for you:   index=healthcheck integrationName="Opsgenie Edge Connector - Splunk" alert.message = "STORE*" "entity.source"=Meraki | rename alert.message AS "Branch" | transaction "alert.id", alert.message startswith=Create endswith=Close keepevicted=true Branch | where closed_txn=0 | spath 'alert.createdAt' | stats sum(duration) as total_duration, latest(Created) as Created by Branch | eval Created=strftime ('alert.createdAt'/1000,"%m-%d-%Y %I:%M:%S %p") | eval percent_uptime = (total_duration / (86400*7)) *100   I moved your rename to earlier (because life is easier this way), added "Branch" to your transaction, left most of that middle bit alone, added the stats to sum the duration of the transactions and to snag the latest "Create" from the event (again by "Branch"), then a bit of cleanup and math. Give it a try.  And as always, if something's not working right start chopping lines off the end of that search until you get back to data that makes sense, analyze it one line at a time going forward being careful to figure out how each step works and what it does and that its results are right (and fixing it if it isn't), then proceeding.  Sort of how I gave you the run-anywhere example, splitting it out into three sets of search so you can see how it builds.   ... View more

There were a few errors, but this should work.  Note I broke out the comparison_date calculation from the eval where you decide if they need to reset or not, to a) make it more clear and b) so you can see the dates/strings it's comparing with. | makeresults format="CSV" data="date 2024-05-09T08:05:00 2024-02-09T08:05:00" | eval epoch_lastLogonTimestamp_date = strptime(date, "%Y-%m-%dT%H:%M:%S") | eval last_logon_total = strftime(epoch_lastLogonTimestamp_date, "%d/%m/%Y") | eval comparison_date = relative_time(now(),"-61d@d") | eval action = if(epoch_lastLogonTimestamp_date <= comparison_date, "reset password", "no change needed")   I think the biggest issue was that the epoch date is the only one you need.  Do your math on it, work with it.  If you need to see it in a more human readable version, you can convert it back at the end.  In this case, 'last_logon_total' is simply unused after you build it.   Happy splunking, and if this helped karma would be appreciated! -Rich ... View more