The Traces table is not only a live log stream. It is also a review surface for repeatable investigations. Use views and exports when a team repeatedly asks the same trace question or needs to share evidence outside the app.
Customize columns
Use the column control to show only the fields needed for the investigation.
Common column sets:
| Investigation | Useful columns |
|---|
| Latency | Status, Started At, Name, Latency, Tags, Attributes, Trace ID, Span IDs. |
| Cost | Name, Cost, Tokens, First span input, Last span output, Prompt, Tags. |
| Quality | Status, Name, Input, Output, evaluator-related filters, Tags, Attributes. |
| Release review | Started At, Name, Prompt, Environment or release attributes, Cost, Tokens, Latency. |
| Support handoff | Trace ID, Session ID, Reference ID, Name, Status, Started At. |
Save a view
When a filter and column setup is useful, save it as a view. Views help teams return to the same operational question without rebuilding filters every time.
Good saved views:
- Production errors in the last 24 hours.
- High-cost traces for a product route.
- Low-evaluation-score traces after deployment.
- Tool failures for a specific workflow.
- Traces for a release or feature flag.
- Behavior-linked traces for a known issue.
Saved views are most useful when the underlying metadata is stable. If route, release, environment, or segment attributes change names frequently, views become less reliable.
Export filtered results
Use export when you need to:
- Share trace evidence with a teammate who is not in the app.
- Attach evidence to an incident review.
- Analyze a filtered set in another tool.
- Preserve a release-review packet.
- Compare results before and after deployment.
The export uses the current filters. Before exporting:
- Check the time range.
- Remove filters that are not part of the question.
- Confirm the result count makes sense.
- Confirm the export does not include data the recipient should not see.
Trace exports can contain production user content, application metadata, raw IDs, and tool responses. Treat exports as sensitive data.
Understand export scope
The live trace table can support prompt narrowing through a prompt filter. Some backend export paths may not support every live-table filter in exactly the same way. If an export result looks broader than the table, re-check the filter set and narrow by time, status, tags, attributes, trace IDs, or span IDs.
For audit-sensitive work, include the filter definition in your incident notes so reviewers know how the export was produced.
Build a review packet
For a serious issue or release review, combine:
- Saved view name or filter summary.
- Export filename and time.
- Representative trace IDs.
- Representative span IDs.
- Behavior link, if the traces are clustered.
- Dataset rows added from spans.
- Evaluator failures.
- Deployment snapshot or rollout decision.
Keep views useful
Review saved views periodically:
- Delete views tied to old incidents.
- Rename views when team language changes.
- Update filters after instrumentation changes.
- Prefer durable metadata such as environment, route, release, status, and evaluator outcome.
- Avoid views that depend on one person’s temporary labels.
Saved views are an operations habit. They are most valuable when your team names the question clearly, such as “Production refund latency over SLA”, not “temporary debug view”.
