Logs

Two kinds of things go wrong with a deployment. The build itself fails, or the deployed code misbehaves once it's running. Vercel splits its logs along that same seam: build logs for what happens during deployment, runtime logs for what happens after.

Build logs

When a deployment fails, this is your first stop. Open the Deployments tab, click the deployment in question, and select Build Logs. You'll see real-time output: dependency installation, the framework build, page generation, and anything your build commands print along the way.

Errors are highlighted in red or marked with error labels. Each step shows up as a clear section, so a failure points you straight at the right phase.

Runtime logs

For everything your app does after it deploys, open the Logs tab in your project navigation. Logs stream in real-time as requests hit your functions, edge middleware, and routes. Each entry shows the timestamp, HTTP method, path, status code, and duration, plus any console output from your code.

The sidebar on the left has filters for route, host, deployment, status code, request type, and more. The filters are how you turn a noisy log stream into the specific view you actually need.

Common debugging patterns

A few patterns worth knowing on day one:

• Users seeing errors? Expand Status Code and select 5xx for server errors or 4xx for client errors. Drill into a specific code to see which routes are responsible.
• A specific route misbehaving? Expand Request Path and click into the route. Now you only see requests for that route.
• Debugging a server component? Expand Request Type and select server components. There are similar options for API endpoints and ISR depending on what you're investigating.

The log view is far more configurable than this, but those three cover most of what you'll hit early on.

Reading a single log entry

Click any log entry to expand it. At the top you get HTTP method, path, status, exact timestamp, and the request ID, the unique identifier you can share with a teammate or with Vercel support to point at exactly this request.

Below that, request details: full path, host, user agent, referrer, search parameters. Depending on the request type, you'll also see function invocation info, external API info, and cache context. At the bottom, total response time and deployment info: deployment ID, environment, and branch. That last bit is what lets you correlate issues with a specific deploy.

Log drains

Vercel keeps logs for a default retention window. For longer storage, custom alerts when errors spike, or dashboards that combine Vercel logs with the rest of your stack, use Log Drains.

Go to Team Settings > Log Drains. From there you can connect to Datadog, Logtail, Axiom, or any custom webhook. Many providers have one-click integrations that take seconds to set up.

From the command line

vercel logs <url> shows runtime logs for a deployment. Add --json for machine-readable output if you're piping to another tool. For build output during a deploy, use vercel deploy --logs to stream it as the build runs.

Recap

• Build logs capture install, compile, and generation output, with failed steps surfaced clearly
• Runtime logs stream every request your deployed app handles, including console output
• Filters by status code, path, and request type narrow logs from "everything" to "what you need"
• Request IDs are shareable identifiers; paste one to a teammate or Vercel support to point at a specific event
• Log drains ship logs to Datadog, Logtail, Axiom, or any webhook for long-term retention and custom alerting
• The vercel logs and vercel deploy --logs commands surface logs in the terminal when you're already there

Follow up docs

• Logs overview
• Accessing Build Logs
• Runtime Logs
• Working with Drains
• Vercel CLI logs