Vercel Traces: Tree and Waterfall Views for Slow Spans

Vercel Traces now render two in-line views inside individual log entries: a Tree view that sorts spans by duration so the slowest appear first, and a Waterfall view that lays every span along a single chronological timeline. Vercel announced the change in its July 10, 2026 changelog. It sounds like a small dashboard tweak — it’s actually the difference between scrolling a flat span list and running a structured performance audit without leaving the log entry.

The two views answer different questions, and Vercel’s own changelog copy doesn’t spell out the distinction. Tree view answers which span is slowest — a ranked suspect list. Waterfall view answers why the request is slow — whether work that could run in parallel is executing sequentially. Mistake one question for the other and you can spend an afternoon optimizing a database query while three serialized fetches were the real problem.

This guide covers what shipped, how Vercel’s trace model actually works, a decision table for which view to open first, a find-the-bottleneck walkthrough on a hypothetical Next.js route, and the size limits and retention windows that decide whether the span you’re hunting is even still there. Everything below is sourced from Vercel’s changelog and documentation — this is a platform changelog, not a press-covered launch, so all claims are vendor-stated and framed that way.

On July 10, 2026, Vercel announced that Traces support tree and waterfall views inside individual log entries in Vercel Logs. The positioning, per the changelog, is that engineers no longer need to leave the log-entry context to inspect span hierarchy and timing — a vendor-stated UX claim, but a plausible one given where the data previously lived.

That location matters more than it first appears. The log-details sidebar already surfaced an “Events” timeline and an “Outgoing Requests” panel before this change — the same underlying span data, readable only as a list. The new views formalize and visualize that data instead of asking you to reconstruct the request’s shape in your head. And because the Logs search bar supports a dedicated traceId field — alongside sessionId and invocationId — a specific trace can be pulled up directly by ID rather than browsed to.

One honesty note before the workflow: this is a low-profile platform changelog, not a press-covered launch. There is no independent third-party benchmark of the views and no community reaction to report — every claim in this post traces back to Vercel’s own changelog and docs, and we hedge accordingly. The walkthrough in section 06 is our own illustrative scenario, not a reported case study.

Vercel’s tracing docs put it plainly: “You can think of a trace as the story of a single request: Request arrives at Vercel CDN → Middleware executes → Function handler processes request → Database query runs → Response returns to client.” If that request lifecycle is unfamiliar, our guide to how Vercel Functions execute requests walks the full path. A span, per the same docs, is a single unit of work inside that story — it carries a name, a start time, an end time, and a duration. The trace is the tree; spans are the nodes.

Coverage is layered. Vercel automatically instruments infrastructure and outbound-fetch spans with no code changes, once Trace Drains or Session Tracing are enabled. Framework spans — the route- and rendering-level detail that makes a Next.js trace actually legible — require the @vercel/otel package; Next.js 13.4+ contributes those spans automatically once OpenTelemetry instrumentation is installed. That framework layer keeps getting more relevant as Next.js itself accelerates — see Next.js 16.3’s Turbopack persistent cache for where build-side performance is heading in parallel.

To see traces in the dashboard at all, Session Tracing must be enabled via the Vercel toolbar — either as a single-page “Page Trace” or an ongoing “Session Trace,” per the docs. The dashboard then renders four visually distinct span types:

Tree view renders the trace as a parent-child hierarchy — which span invoked which — and applies one opinionated default that does most of the work:

That single sort order changes the triage workflow. A flat span list — or an alphabetical or insertion-ordered tree — makes you scan and expand every branch to find the expensive one. Duration sort means the worst offender is the first thing you see, and because the hierarchy is preserved, you also see which subtree owns the time: a slow parent with fast children points at the parent’s own work; a slow parent whose time is fully explained by one slow child pushes the investigation one level down.

What Tree view doesn’t tell you is anything about time relationships. Two 300 ms spans look identical in a duration-sorted tree whether they ran simultaneously or back-to-back — and that distinction is often the entire performance story. That’s the waterfall’s job.

Waterfall view lays every span along a single chronological timeline. Per Vercel’s changelog, that is what makes parallel execution — spans running side by side — visually distinct from sequential, blocking work. Spans that overlap in time occupy the same horizontal region; spans that serialize stack end-to-end, each starting only after the previous one finishes.

The waterfall is where the most common Next.js performance defect becomes undeniable: independent async operations awaited one after another. In a tree view, three sequential 300 ms fetches read as three medium spans — nothing alarming. On a timeline, they form a staircase with each step starting exactly where the last ended, and the staircase shape itself is the diagnosis. The fix — batching independent work with Promise.all — collapses the staircase into overlapping bars, and the waterfall is also the view that proves the fix landed.

Gaps matter too. Empty horizontal space between spans — time the request spent with no span active — points at work that isn’t instrumented yet, or at platform-level effects like cold starts that sit outside your application code.

Vercel’s changelog describes the two views independently — it never gives you the side-by-side. The table below is our own workflow framing built on the confirmed mechanics: duration-sorted hierarchy on one side, chronological timeline on the other. Bookmark the last row.

The pattern that emerges: Tree view is a triage tool — open it first on an unfamiliar slow route to get a ranked list of suspects in seconds. Waterfall view is a diagnosis and verification tool — open it once you have a suspect, to understand whether the problem is one expensive operation or an execution-shape problem, and open it again after the fix to confirm the shape actually changed. Neither view replaces the other; the workflow is a loop between them.

Here’s the loop in practice, on a hypothetical, illustrative scenario — the timings below are ours for teaching purposes, not measured production data. Picture a Next.js Server Component page that awaits a CMS content fetch, then a database query, then a pricing-API fetch, then renders. None of the three data operations depends on another’s result — they’re just written as consecutive awaits.

Step 1 — Tree view. The route’s p95 has crept past a second, so you pull up a slow request in Vercel Logs and open the trace. Duration sort puts the CMS fetch on top at 380 ms, the pricing fetch next at 310 ms, the database query at 240 ms. Useful — but no single villain. Nothing here explains a 1,000 ms+ request on its own, and this is exactly the case where tree view alone sends you optimizing the wrong thing.

Step 2 — Waterfall view. Switch views and the story changes instantly: three bars in a staircase, each starting where the previous one ends, no overlap anywhere. The problem isn’t any one span — it’s that ~930 ms of independent work is running single-file. The waterfall also shows a small gap before the first span; on a cold invocation that kind of dead time is platform-level, which is the territory covered by Fluid Compute’s cold-start elimination rather than by your application code.

Step 3 — the fix. Wrap the three independent operations in a single Promise.all, redeploy, and re-trace the route.

Step 4 — verify in the waterfall. After the fix, the three bars overlap in the same horizontal region and total request time collapses toward the longest single branch plus the render: 380 ms + 90 ms ≈ 470 ms in this illustration, down from the 1,020 ms sum of all four sequential steps. The tree view, notably, looks almost unchanged after the fix — same spans, same durations, same sort order. Only the waterfall proves the execution shape changed. That asymmetry is the whole argument for having both views one click apart.

A trace view is only as good as the spans that survive to reach it, and Vercel documents two entirely separate limit systems that govern that — scattered across two docs pages. Traces are measured in compressed span data; runtime logs are measured in lines and kilobytes of console output. Engineers debugging “why did my span disappear” routinely check the wrong one. The consolidated reference:

Two more documented gotchas belong in the same mental file. First, custom spans from functions on the Edge runtime don’t appear in Session Tracing or Trace Drains — a real coverage gap for teams mixing Edge and Node.js functions, since your most latency-sensitive routes may be the least observable ones. Second, if you run Sentry alongside Vercel’s instrumentation, Vercel documents adding skipOpenTelemetrySetup: true to the Sentry SDK v8+ init in instrumentation.ts so the two don’t break trace propagation between them. And note these limits all concern runtime observability — build logs are a separate surface with their own recent changes, covered in how Vercel redacts secrets in build logs.

One boundary worth drawing precisely, because generic “observability” content blurs it constantly: this is platform observability — Vercel tracing its own request path through CDN, middleware, functions, and outbound fetches. It is not agent or LLM observability, which traces prompts, tool calls, and token spend through tools like LangSmith, Langfuse, and Arize. That layer has its own economics and its own stack, covered in our guide to the AI-agent observability stack. An AI-heavy Next.js app genuinely needs both: the platform trace tells you the route spent 4 seconds in an outbound fetch; the agent trace tells you what the model was doing inside it.

The trend this release fits is bigger than one changelog entry: platforms are pulling capabilities in-house that used to require a dedicated APM subscription just to get started. A duration-sorted span tree inside the log entry is triage that previously meant exporting traces elsewhere first — and every step removed between “this route is slow” and “this span is why” makes it more likely the investigation happens at all. Our working projection: expect the in-dashboard layer to keep absorbing first-response debugging while exported traces via Drains remain the home for long-horizon analysis — and expect the Edge-runtime custom-span gap to become more visible as more teams route latency-critical paths through Edge. This is exactly the layer we tune in our web development engagements: the fix is usually cheap once the right view has named the bottleneck.