In an enterprise installation of CLM, there are many components which may have timeouts configured by default or through user customization. Example:
* Cross application timeouts within CLM
* "Dashboard query" timeouts in CLM
* Various Connection timeouts
* Reverse proxy read timeouts
* Caching proxy timeouts
* Timeouts defined on other servers in the network.

The practical value of each timeout is that it indicates that an operation has taken longer than expected. But I find there are two challenges:
1. As you add a component such as a WebSphere HTTP Plug-in for a reverse proxy, you introduce a new set of default timeout behaviors  which may need tuning to be appropriate for CLM.
2. It is not always obvious from logs or browsers that a timeout has occurred. For example, most reverse proxies will show "status 500" not for example "Status 500: ServerIOTimeout occurred in the proxy". A timeout can also trigger other "red herrings" such as authentication exceptions.

The best way to uniquely identify each timeout may be if you set each timeout in your system to a unique value and ensure that you document each of them. That way when an operation consistently ends in 113 seconds, you can go directly to the 113s timeout and investigate if/why that one occurred. But this assumes that you can identify each timeout that would apply in your system.

But I wonder if there are ways to configure WAS, IHS, Squid, Jazz Foundation and so forth, to issue explicit messages when timeouts occur.

What best practices do people use in this area?

Which timeouts are always used for diagnostic purposes and to inform users of errors, and which ones (if any) can save server resources?