Traces
Traces in the Monitor area — route /monitor/traces, reachable by direct link rather than from the sidebar.
This page lives in the Monitor area at /monitor/traces. It is not in the sidebar — it is reached by a direct link, or from another page that links to it.
At a glance#
| Dashboard route | /monitor/traces |
| Area | Monitor (monitor) |
| In the sidebar | No — reachable by direct link |
What it does#
Traces lists captured transactions — page loads, client-side navigations in a single-page app, and any custom transactions you start yourself — and drills into a selected one as a span waterfall showing what happened inside it and in what order.
A percentile table tells you a navigation took 3 seconds. A span waterfall tells you it spent 2.4 of them waiting on one sequential request that could have run in parallel. That is the difference this page exists for.
When to use it#
When a slow operation is composite and you need to see the sequence. Any flow that fans out into several requests, or where you suspect something is serial that should be concurrent, is best understood here.
Custom transactions are worth the instrumentation for your critical flows — checkout, search, sign-in. Those are the ones where you will want a waterfall at 2am.
Workflow#
Filter to the transaction type you care about
Page loads and SPA navigations have completely different shapes. Comparing them tells you nothing.
Open a slow one, not a median one
The point of a waterfall is the pathological case. Sort by duration and open the tail.
Look for stairs
Spans that start one after another where they could overlap are the most common and most fixable finding. Gaps between spans are the second — that is time nobody accounted for.
Follow a network span through
The Network drawer links here by trace id, so a slow endpoint and the transaction that waited on it are two clicks apart in both directions.
Permissions and prerequisites#
Web apps only. Page loads and SPA navigations are captured automatically; custom transactions require you to start and finish them in your own code — see the performance SDK guide.
Limits and edge cases#
Not every transaction is kept. Capture is sampled, so this is a representative set rather than a complete log. Do not use it to count anything.
An unfinished transaction is not a trace. A custom transaction whose end call is skipped — because of an early return or a thrown error — never arrives. Finish them in a
finally.Span detail is only as good as your instrumentation. Automatic capture covers navigation and network; work inside your own functions is invisible unless you add spans for it.
Troubleshooting#
Custom transactions never appear. Check that every exit path finishes the transaction, and that the name is stable — a name built from a variable creates a new transaction type per value.
A waterfall has one long span and no detail. That span had no children. Add spans around the phases you suspect, then look again.