Investigation Playbooks
Slow API After Deploy
Use this playbook when latency rises after a release and you need to decide whether the deploy, a dependency, or runtime pressure is involved.
Situation and outcome
Use this playbook when latency rises after a release and you need to decide whether the deploy, a dependency, or runtime pressure is involved.
A service or endpoint is slower after a new version or deployment. Users report slow pages or API calls near release time. An issue or alert points to latency shortly after a change.
By the end of this playbook, you should know whether the release is a likely cause, which service or endpoint changed, and which trace, log, or runtime evidence supports the next action.
Evidence to collect
- Release window
- Record the version, deployment, environment, and time range before comparing behavior. Keep the same filters when moving between pages.
- Endpoint delta
- Use the affected endpoint as the comparison unit. A service-wide average can hide one route that changed sharply.
- Trace proof
- Capture at least one slow trace from before and after the release, then compare the span that owns most of the added time.
Investigation path
Follow the path in order until the evidence points to a service, dependency, release, runtime signal, or setup gap.
- 1
Open Releases and confirm the service, version, deployment, environment, and time window.
- 2
Open the affected service and compare endpoint latency before and after the release.
- 3
Open Traces for the slow route and inspect spans that dominate request time.
- 4
Use Logs with the same service, time range, version, and deployment context to find warning or error events.
- 5
Check Runtime if traces do not show a single slow dependency.
- 6
Use Issues to see whether Vight already named a release-adjacent regression.
Decision point
If one span dominates the trace, inspect that dependency or endpoint next. If several endpoints slow down together, compare Runtime and Infrastructure before assigning the release. If latency returns to baseline after rollback, keep the release context attached to the issue.
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
Share the service, endpoint, environment, version, deployment, and exact time window.
Evidence 2
Attach representative slow traces and the span or dependency that changed most.
Evidence 3
Include related logs only when they explain the timing change, error, retry, timeout, or fallback.
Evidence 4
State whether runtime or infrastructure pressure was clean, suspicious, or still unknown.