What a good trace looks like

A trace is only useful if someone can read it under pressure. We redesigned ours around one question: can an on-call engineer understand a run in thirty seconds?

Above the fold

1. Outcome and total time.

2. Cost, with the most expensive step highlighted.

3. Every tool call in order, with status.

4. The policy checks that ran, and which ones passed.

Below the fold

Full prompts, raw model output and token counts. Important, but rarely the first thing you need.

Design choices

• Monospace for anything a machine produced.

• Status in words (OK, RETRY, FAIL), not colours alone.

• Durations right-aligned so outliers jump out.

If you have to scroll to find out whether a run succeeded, the trace failed.