For every long-running request, the Performance Monitor captures and logs HTTP request data, (limited) HTTP session data, JDBC call data and periodically gathered stack traces. The HTTP request and (limited) HTTP session data can be used to identify the user, the record, the search, the tool, etc. The JDBC call data, including timings, full SQL text and bind parameter values, can help isolate a variety of issues, including poorly performing queries, too many queries being executed, or too much data being returned. The periodically gathered stack traces can help identify performance issues in custom rules, custom Java blocks, or even core TeamConnect code.

You can configure a threshold, in milliseconds, for "stuck" requests. As soon as a request exceeds this stuck threshold, the monitor immediately logs all of the data it has gathered for this request so far to make sure this information is not lost (since normally long requests are only logged upon completion). Also, if any email addresses have been configured, the monitor will email an alert with the same data that it logged for the stuck request. If the request later completes, a second email is sent that the request has completed (become "unstuck").

The TeamConnect Performance Monitor doesn't capture any information related to hardware utilization. Hardware utilization data can be very valuable and can be captured by a variety of tools. However, often spikes in hardware utilization (e.g. CPU and memory) are caused by long-running requests and not vice versa. Of course, once CPU or memory reaches its limits, this can cause all requests to run slow, but often the key is to identify the initial long-running request(s) which triggered the CPU or memory spike in the first place.