Investigation Playbooks
Runtime Pressure
Use this playbook when a service looks slow or unstable and runtime signals may explain the behavior.
Situation and outcome
Use this playbook when a service looks slow or unstable and runtime signals may explain the behavior.
Latency rises without one obvious slow dependency. Errors increase around CPU, memory, allocation, event loop, thread activity, or exception changes. Several traces show broad delay rather than a single dominant span.
By the end of this playbook, you should know whether runtime pressure is the primary cause, a supporting symptom, or unrelated to the latency and error behavior you are seeing.
Evidence to collect
- Pressure window
- Compare runtime pressure against the same service, environment, and time range as the user-facing symptom.
- Request impact
- Use traces to verify whether requests slowed broadly, failed at one dependency, or waited inside a specific operation.
- Change context
- Check releases and logs for deployment, configuration, lifecycle, or traffic changes around the pressure start.
Investigation path
Follow the path in order until the evidence points to a service, dependency, release, runtime signal, or setup gap.
- 1
Open the affected service and confirm the time range, environment, and main symptom.
- 2
Open Runtime for the same service and compare pressure signals with the symptom timeline.
- 3
Open Traces to see whether requests slow down broadly or at a specific span.
- 4
Open Logs for warnings, exception bursts, or lifecycle events around the same timestamps.
- 5
Check Infrastructure if several services on the same resources degrade together.
- 6
Check Releases if pressure starts near a deployment or version change.
Decision point
If runtime pressure aligns with latency, treat runtime as a primary cause candidate. If runtime is clean but one span is slow, inspect that dependency instead. If runtime metrics are missing, use the runtime troubleshooting guide before continuing.
Choose the next action only after the evidence explains both impact and ownership. If the evidence is stale, mismatched, or filtered too narrowly, widen the investigation before assigning work.
Handoff
A useful handoff gives the next responder enough context to reproduce the evidence without replaying the whole investigation.
Evidence 1
Name the runtime signal that changed and the service or environment where it changed.
Evidence 2
Include traces showing whether the pressure produced broad delay or a specific span problem.
Evidence 3
Include logs that explain lifecycle events, exception bursts, retries, or resource-related warnings.
Evidence 4
State whether infrastructure pressure is also present or whether the signal is service-local.