# Workflows, Sessions and Traces (/docs/dashboard/workflows-sessions-traces) Three tabs slice the same traffic at three different sizes. Getting them right depends entirely on what your app tags each call with; see [Sessions and traces](/docs/concepts/sessions-and-traces). | Tab | One row is | Comes from | | ------------- | ----------------------------------------------------------------------- | ------------------------------------------------ | | **Workflows** | A named agent loop in your app, like `support-chat`. | The workflow name you wrap your agent code with. | | **Sessions** | One conversation. | The `session_id` your app sets. | | **Traces** | One agent run — one user message and the whole agent loop it triggered. | The run id the SDK carries through a request. | A **turn** is one trace. Turns that share a session id collapse into one session. Runs with no name roll up under *(unnamed)*. ## Workflows [#workflows] Ranked by spend, one page of 50, sortable by **Cost / Runs / Tokens / Calls / Recent / Drift**. | Column | Shows | | ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | | **Workflow** | The name, with how many models it used. | | **Runs** | Executions in the range. | | **Total cost**, **Avg cost / run** | Spend, and the per-run figure that drift is measured against. | | **Avg calls / tokens / tools / duration per run** | The shape of a typical run. | | **Errors** | Failure rate. | | **Signals** | Badges: a cost-drift percentage (only at +30% or more), a tool error rate, and **Loop** when loop rules fired. | | **Last run** | Recency. | The detail view adds cost over time, a **cost-driver attribution** panel explaining *why* per-run cost moved against the 30-day baseline (including model-mix shifts), tool timing and reliability, token and prompt-composition breakdowns, and the firewall actions that hit this workflow. Drift gauges need **20 runs** of history before they render anything. ## Sessions [#sessions] Six KPI tiles — sessions, model calls, total cost, total tokens, firewall actions, dry-run catches — then a table of **Session · Turns · Model calls · Tokens · Cost · Duration · User · Last active**, searchable by session id and sortable by recency, cost, tokens, turns or duration. Open one and you get its turns as an accordion, a per-turn chart (cost, tokens or duration), usage split by modality, and — once there are 20 comparable sessions — a gauge placing this session against a typical one. ## Traces [#traces] A rail of runs beside a detail pane, filterable by **Loop / Reroute / Blocked / Error** and shareable by URL. Cost cells carry a prefix when the number is incomplete: `≥` means some call had no price, `~` means it was approximated. The detail view is the deepest screen in the product: a waterfall of every span, per-span prompt and response composition, a cost breakdown table with the unit, quantity and rate behind each dollar, reroute annotations, and — when a loop rule fired — the **loop fingerprint sequence**, one chip per call the detector evaluated with the repeating cycle outlined. ## What to look for [#what-to-look-for] * **Every session has exactly one turn** — `session_id` isn't threaded across turns, so the grouping is doing nothing. Threaded properly, one conversation is one row with many turns. * **All runs under *(unnamed)*** — nothing wraps your agent code with a workflow name, so per- workflow drift can't be attributed. * **A run with far more calls than its siblings** — a loop candidate. Check its fingerprint. * **A `≥` prefix on many rows** — real spend is higher than shown; see [Unpriced calls](/docs/dashboard/models-and-unpriced). * **Loop chips on a workflow with no loop rule armed** — the detectors are watching but only alerting. ## Next [#next]