Product Guides

Traces

Use Traces to find slow or failed requests, then open trace detail to read the full request path.

TracesLatencyRequests

Overview

Use Traces when you need request-level proof. Traces show the actual path of one request, where time was spent, which span failed, and which logs are attached to that request.

Use this page after you know the approximate symptom and need to decide which evidence should come next. Keep the service, environment, and time range consistent as you move from summary pages to request-level detail.

How to read this page

Filter by service, environment, time range, and error state before comparing traces. Use duration and status to choose traces worth opening. Read trace detail from the root span outward, then use related logs for event-level context.

Duration
Long traces tell you which requests were slow. The slowest span tells you where to inspect next.
Status and errors
Failed traces connect status, service, route, error, and span evidence in one path.
Related logs
Logs attached to a trace explain application decisions that span timing alone cannot show.

Investigation workflow

Use this sequence when you need to move from a broad symptom to evidence you can share with another teammate.

  1. 1

    Filter to the affected service, route, and incident window.

  2. 2

    Open a slow or failed trace and find the first span where timing or status becomes abnormal.

  3. 3

    Use related logs to confirm whether the application reported a meaningful event at that moment.

Interpretation note

Do not treat one trace as the whole incident. Compare a few representative traces. Do not ignore the root span when a nested span looks suspicious. Do not use trace filters so narrowly that healthy comparison requests disappear.

Related pages