What happened
Vercel Logs now shows two new ways to view a trace: Tree and Waterfall. A trace is the story of one request as it moves through your app, from the CDN, through middleware, into your function, out to a database call, and back to the client. Each step in that story is called a span, and every span has a start time, an end time, and a duration.
The Tree view groups spans by parent and child, and sorts them so the slowest span shows up first. The Waterfall view lays every span on a single timeline, so you can see what ran in parallel and where time actually went. Both are available directly inside a log entry in Vercel’s tracing dashboard, no separate tool required.
Why it matters
“My app feels slow” is one of the hardest bugs to track down without visibility into what’s actually happening during a request. Is it the database query? A slow third-party API call? Vercel’s own routing and caching layer? Without a trace, you’re mostly guessing, and adding console.log statements everywhere just to time things.
Vercel already auto-instruments infrastructure and outbound HTTP calls for every function, so this isn’t asking you to add tracing code. It’s giving you a better way to read data Vercel is already collecting. The Waterfall view in particular answers a question logs alone can’t: was that database call and that API call slow because they ran one after another, or because something else was blocking them the whole time.
Who should care
This matters if you deploy to Vercel and have ever had a page or API route that felt sluggish without an obvious cause. It’s less useful if your app is simple enough that nothing’s ever felt slow, but it’s worth knowing the option exists before you need it.
What builders should do next
Tracing needs to be turned on before you can see it. Open your project’s Logs section, click the toolbar’s Session Tracing toggle, then reload the page or hit the endpoint you want to investigate. Vercel starts capturing infrastructure and fetch spans for that session.
Once you have a trace, open the request in Logs and click Trace at the bottom of the details panel. Start with the Tree view since it’s sorted slowest-first, so the worst offender is right at the top. Switch to Waterfall if you need to see whether slow steps were sequential or overlapping.
If you want deeper visibility into your own code, not just Vercel’s infrastructure, you can install the @vercel/otel package to add custom spans around specific functions. That’s an extra step beyond what ships by default, but it means a slow database call inside your own logic shows up in the same trace instead of just as one black-box span.
Debugging “it’s slow” used to mean adding timers and guessing. Now the timeline is already there, you just have to turn it on and look.
End of article