Use an affected action as the investigation boundary
| Reported problem | First evidence to collect |
|---|---|
| Slow login | Client location, failure pattern and the available connection or service records. |
| Slow administration | Specific action, time interval and concurrent application/resource activity. |
| Late quotes | Affected instrument and source-to-delivery timestamps where available. |
| Slow external response | Correlated request, route, destination and known outcome. |
Compare an affected case with a normal case that has a similar configuration. An instrument with a different trading session or a client on another route is not automatically a valid control.
Build a timeline before attempting a fix
Record recent configuration changes, scheduled work, connection events and the start of the symptom. Observe the application together with CPU, memory, storage and relevant network conditions. Mark uncertainty when clocks or records do not allow a clean correlation.
A quiet server can still depend on a slow external service. Conversely, a busy resource is not necessarily responsible for the delayed action. Investigate the boundary whose behaviour changes with the symptom and test that hypothesis.
Confirm the improvement with the same workflow
Choose an authorised, reversible change and document the intended effect. Repeat the original observation afterwards, including the normal control where practical. Keep the result even when the change does not help; it narrows the diagnosis.
Continue with capacity diagnosis, feed troubleshooting or connectivity timing according to the evidence. A technical review brief should contain the timeline and observations rather than credentials or unnecessary client records.