Guides
From a Slow Endpoint to Runtime Pressure in One Investigation
A practical workflow for connecting latency, traces, logs, runtime pressure, and deploy context without rebuilding the incident in five tools.
· Vight team · 6 min read
Investigation guide
Follow the evidence.
A latency alert tells you where an investigation starts, not why the request slowed down. The useful question is whether the delay lives in application code, a dependency, runtime pressure, or a change that just reached production.
The fastest path is to keep the scope fixed while moving between signals: the same service, environment, endpoint, and incident window.
01
Start with the affected request shape
Confirm that the regression is broad enough to matter. Compare request count, error rate, p95, and the slow tail before choosing a representative trace.
One unusual trace is evidence, not a population. Look at several examples from the same route and window so an isolated retry or cold start does not become the whole diagnosis.
02
Move through the trace, not around it
The waterfall shows where wall time accumulated. Follow the longest child span, then check whether nearby logs and dependency calls agree with that story.
When the application span is long but downstream work is not, compare runtime pressure over the same period. Allocation bursts, thread-pool starvation, and long GC pauses often explain time that no dependency span owns.
Dependency time
A long database or HTTP child span points outside the process.
Unowned time
A long parent with short children points back toward runtime or application work.
Change time
A deploy marker narrows whether the regression follows a version or workload shift.
03
Close with a falsifiable handoff
Write the conclusion so the next person can disprove it: name the route, window, representative trace, suspected bottleneck, and the evidence that makes alternatives less likely.
That record is more valuable than a screenshot collage. It preserves the path from symptom to cause and makes the eventual fix measurable against the same signals.
A good investigation changes signals without changing scope. Keep the request and time window fixed, and the system starts telling one coherent story.