Skip to main content
A trace is a single end-to-end run of your agent: every step, tool call, retrieval, and hand-off from the incoming request to the final answer. Traces are the raw material of everything Glassray does - they get classified into flows, judged against your spec, and grouped into deviations. Glassray stores the full provider document for each trace, so you can inspect the whole run later - in the dashboard, or over the MCP server with get_trace.

​
Getting traces in

Connect Glassray to your traces one of six ways - Langfuse, LangSmith, PostHog, Better Stack, Vercel, or OpenTelemetry. The Quickstart walks through it end to end.

​
Filtering what gets pulled

A connected source can carry an optional filter so only the runs you care about are ingested. You can narrow by trace name and scope (the root run’s name, or a descendant step’s name), so noisy or irrelevant traces never land. Filtering is applied at ingest - non-matching traces are simply not stored. Filter changes are go-forward: re-sync to apply a new filter to fresh traces.

​
Filtering in the dashboard

Once traces are stored, the Traces view can slice them by any custom attribute a trace carries - a merchantId, a branch, a commit. Add a filter, pick the attribute, and choose an operator: is, is not, contains, exists, regex matches, or a numeric comparison. A new attribute is filterable the moment it first appears on a trace, no setup needed. See SDK metadata for attaching attributes from your own code.
Once traces are flowing, head to Flows to see how they’re grouped, or Ask Glassray to explore them in natural language.