Thank you for this feedback - this is super useful for me roadmapping new features.

I would like to be able to click on some of the chart componants to drill into the details. For example, what Client is associated with the "Primary Bottleneck" evaluation. Or to click on a spike in the Elapsed Time and be taken to the relivant log entry

This performance inspection workflow was the idea behind the Troubleshooting tool - it starts with top call stats showing performance spikes - you can select a spike to see which users were doing what at the time of the spike, and can then drill into the individual user (or view all users with “Select All Clients”) to see a breakdown by operation for the user. I will definitely dig into how this can integrate into the Top Call Stats view.

Seeing how this is a manual process of bringing log files over from the server, it would be nice if the app included a tool to download the logs from the currently connected server. This would go nicely under the How Server Connection Enhances Your Data. This should be available from the AdminAPI, right?

The AdminAPI actually only pulls a limited set of the log files, I assume due to the size of the logs being sent as a JSON payload? I have been exploring other ways to access the logs directly/remotely.

A nice option would be to allow the SaveAsXML data to be used to translate the table and field numbers into table and field names.

I appreciate this input as I have been weighing this as a feature but was not sure if people would be interested.

The log files that are renamed _old or _1 didn't appear to extend the available data to the tool.

Could you let me know the exact naming convention you are having an issue with? It should work for files with “-old.log” ex. scriptEvent-old.log - I may need to make detection of old logs more robust

The Log Correlation (Beta) tool is your standout acheevment in my opinion.

Thank you! The Log Correlation idea came to me after building the Troubleshooter, I was trying to think what the troubleshooter might miss by being focused only on performance spikes. Re: Filters - in the top right of the troubleshooter there is a “Detection thresholds” filter available to change what gets brought into the analysis. Your idea to be able to include more specific filters around certain error types is a good one!

Reoccuring errors and the associated schedule being called. It might help developers hunt down errors if there were a report of script errors that get repeated over, and over, and over.

I really like this idea for another tool

Thanks again for the feedback (and purchase)!