View and debug traces

Open Traces and set the time range

In the platform sidebar, go to Logs → Traces, or open the Traces page.

Set the time range in the upper-right corner to cover the incident. The Time column includes the timezone used to display each timestamp.

Narrow the table to candidate traces

Select Filter, then choose the field that describes the symptom. The filter builder includes identifiers such as Trace ID, Thread ID, and Customer ID; operational fields such as Workflow name, Errors, Duration, Status, and token counts; and dimensions such as Provider, Model, and Custom properties.

Use Add filter group when the investigation needs another group of conditions. Check the resulting rows before saving the filter setup.

Show the columns that help answer the question

Open the table settings control to choose the sort field and direction, and to show or hide columns. A useful default investigation layout is:

• Time and Workflow for context
• Duration for slow runs
• Input, Output, and Total for token usage
• Spans for unexpectedly long agent paths
• Cost and Errors for impact

Show Trace ID when you need to correlate a row with application logs. Hide identifiers and API-key columns before sharing a screenshot.

Save a repeatable investigation view

After confirming that the filters return the intended traces, select Save view and give the view a specific name, such as Production errors or Slow checkout traces.

A saved view lets the team return to the same filter setup without rebuilding it. To update, duplicate, or reuse views, see Views and saved filters.

Open a trace and read its execution

Select a row to open the trace workspace. Keep these regions connected while you investigate:

1. The selected trace in the results table.
2. The nested span hierarchy, which shows parent-child execution order.
3. The duration timeline, which shows when each span ran and how long it took.

Indented spans are children of the span above them. Expand a branch to inspect its work, then compare its duration bar with neighboring spans. The longest bar is the best place to begin a latency investigation, but it is not automatically the root cause of an error.

Focus the hierarchy on relevant span types

Open the span-type filter in the trace workspace. Search for a type or select only the types relevant to the investigation, including Agent, Chat, Evaluator, Function, LLM call, Root trace, Task, Tool, and Workflow.

Examples:

• Show Tool and Task spans to debug a failed tool path.
• Show LLM call and Chat spans to inspect prompt and response behavior.
• Show Agent and Workflow spans to understand orchestration and handoffs.

Filtering changes what is visible in the hierarchy; it does not change the stored trace.

Inspect the suspicious span

Select a span in the hierarchy, then use:

• Span to read the exact input and output captured for that operation.
• Metadata to inspect its identifiers, model and provider context, and attached custom properties.
• The content-format selector to switch among the representations available for that span.

For a model call, compare the actual input with what the application intended to send. For a tool call, compare the tool arguments with its returned value. Then move one level up the hierarchy and verify how the parent used that output.

Confirm the cause before changing the application

Work from the earliest span that contains incorrect data, not merely the last span that displays the failure.

Once the evidence supports a cause, copy the trace identifier into the engineering issue and record the time range, saved view, failing span, and expected behavior. This gives another investigator enough context to reproduce the finding.

Open Threads and find the session

Open the Threads page, choose a time range, and filter or sort the table to find the thread. Useful columns include Thread ID, System, User, Cost, TTFT, Total, and Status.

Inspect the thread context

Select a row to open the thread detail panel. Review the Thread ID, Customer ID, cache status, and custom properties to confirm that this is the reported session. Expand Deployment when you need the available deployment context.

Return to the traces in that thread

Copy the Thread ID, open Logs → Traces, and filter by that value. Order the traces by time, then open the run where the behavior changed and continue through its span hierarchy.

This preserves the distinction between the levels: the thread supplies session context, the trace explains one run, and the span shows one operation.