Tracing dashboard

What you'll build

Step-by-step build

1. 1

   Model traces and spans

   Define a trace as one request and a span as one step inside it, with each span carrying a parent id so steps nest into a tree. Decide the fields every span records: name, type, start, end, tokens, cost, status, input, and output. This data model is the whole foundation of the dashboard.

2. 2

   Instrument the app

   Wrap every model call, tool call, and retry so it opens a span on entry and closes it on exit, attaching timing and token counts. Use a context that carries the current trace id so nested calls attach to the right parent automatically. Either use Langfuse's SDK or your own lightweight tracer.

3. 3

   Compute cost per span

   Turn prompt and completion tokens into a dollar cost using a per-model price table. Attach the cost to each span and roll it up to a total on the trace. Now every request has a visible price, not a mystery bill.

4. 4

   Ingest and store

   Send finished spans to an ingest endpoint that writes them to Postgres or Atlas, or push them to a self-hosted Langfuse. Batch and send asynchronously so tracing never slows the user's request. Index by trace id, time, and status for fast queries.

5. 5

   Build the waterfall view

   Render each trace as a timeline where nested spans sit under their parents and bar width shows duration. Clicking a span reveals its full input, output, tokens, and cost. Seeing the slow or expensive step at a glance is the core payoff.

6. 6

   Add search and filters

   Let users filter traces by status, cost, latency, and time range, and search within inputs and outputs. This is how you find the one failing or expensive request among thousands. Make errored traces easy to jump straight to.

7. 7

   Add aggregates and alerts

   Chart cost per day, p95 latency, and error rate over time, and fire an alert when a threshold is crossed. Add sampling so a high-traffic app can trace a representative fraction instead of everything. These turn the dashboard from reactive to proactive.

8. 8

   Deploy and document

   Host the dashboard, wire a real multi-step app to emit traces, and confirm a full request shows up as a connected waterfall. Write a README with the data model, a screenshot of a real trace, and how to instrument a new app. Show a debugged slow step, because that is the value.

Done when

• ✓A single request appears as one trace with all its steps nested correctly.
• ✓Every span shows latency, tokens, and cost, and the trace shows the total.
• ✓You can filter to the slowest or most expensive traces and open the offending step.
• ✓Tracing adds negligible latency to the traced request itself.

Ship it

Run a self-hosted Langfuse or your own ingest service with traces in Postgres or Atlas, and host the waterfall UI on Vercel, all on the free tier or AWS free tier. Instrument at least one real multi-step app to emit traces. Put the data model, a screenshot of a real trace, and instrumentation instructions in the README.

What it proves: You can make an LLM app observable, tracing every step with latency, tokens, and cost so it can be debugged and optimized. Observability is mandatory in production AI.

Paste this into Cursor, Claude, or ChatGPT and build it step by step.

You are my senior AI engineer pair. Help me build "Tracing dashboard" step by step. Stack: self-hosted Langfuse (open-source LLM tracing) or my own trace/span model, FastAPI or NestJS for the instrumented app and span ingest, Groq free tier for the model calls being traced, Postgres or MongoDB Atlas (free M0) for storage, and Next.js for the waterfall UI.

Tracing means structured logging of every step in a request, viewed as one connected trace; a span is a single step and a trace groups all the spans of one request.

Requirements:
1. A data model where a trace holds nested spans via parent ids, each with name, type, timing, tokens, cost, status, input, and output.
2. Instrument every model call, tool call, and retry to open and close a span, carrying the trace id through nested calls.
3. Compute per-span cost from tokens and roll it up to the trace total.
4. Ingest spans asynchronously so tracing never slows the request, and store them indexed by trace id, time, and status.
5. A waterfall timeline UI with per-span detail, plus search, filters, and simple cost/latency/error aggregates.

Work in this order: data model, instrumentation, cost, ingest and storage, waterfall UI, then search and aggregates. STOP after each step so I can test. Do not write the whole app at once.