How to View Vercel Logs: Dashboard, CLI, and Log Drains

Last verified on Nov 8, 2026.

Vercel keeps two kinds of logs you will use most: build logs, which show a deployment's progress, and runtime logs, which capture what your functions and middleware write while serving requests. You read them in the dashboard, with vercel logs, or by forwarding them with a log drain. This guide covers each, the limits that catch people out, and how long logs last.

Build Logs vs Runtime Logs

Build logs record the build tools' versions, warnings, and errors during the build, and the files and dependencies that were installed or compiled. They are available on all plans and are reached from the deployment, for example from the production deployment tile. They are not in the Logs tab.

Runtime logs cover everything generated by Vercel Function invocations in preview and production, including console.log output, plus Routing Middleware invocations. Static requests appear only when they serve from cache. For every static request, use a log drain. Runtime logs are available on all plans.

Viewing Runtime Logs in the Dashboard

1. Open the project in the dashboard.
2. Choose Logs in the sidebar.
3. Filter, search, and open a row to inspect it.

Logs are grouped per request, and each write to standard output becomes its own entry. Each row shows the host, status, function type, and request ID. Opening a row shows details such as region, cache status, function runtime, duration, and memory use, and the individual log messages in order. You can share an entry by copying the URL.

Live mode in the timeline filter follows logs in real time. All times are UTC.

Filters and Search

The sidebar filters by timeline, level, route, host, deployment, resource, request type, method, path, cache status, status code, environment, and branch. The level filter shows requests that contain Warning, Error, or Fatal logs. Streams map as follows: stdout is info, stderr is error, and console.warn is a warning in streaming functions but an error in non-streaming ones. Requests with a 4xx status are marked Warning, and 5xx are marked Error.

Free text search covers only the message and requestPath fields. Everything else is a filter. The search bar accepts field filters such as status, level, requestId, deploymentId, environment, and branch. Route is the pattern in your code, like /blog/[slug], while Request Path is the real path, like /blog/my-post.

Retention and Limits

Runtime logs are stored for a limited time that depends on your plan:

With Observability Plus you can view up to 14 consecutive days within the 30-day window. Plan limits apply as soon as you upgrade.

Per request, Vercel allows 256 log lines, 256 KB per line, and 1 MB in total. If you exceed these, you can only query the most recent logs. Keep log lines short and structured, and avoid dumping whole payloads. See structured logging and log retention.

Querying Logs with the Vercel CLI

Run vercel logs from a linked project directory. By default it returns the latest 100 records from the last 30 minutes, across production, preview, and custom environments. This describes CLI v64.0.0 and later. Older versions had different flags.

# Runtime logs from the last 30 minutes
vercel logs

# Production errors from the last hour
vercel logs runtime --environment production --query 'level:error' --since 1h

# Errors mentioning timeout
vercel logs runtime --query 'level:error AND timeout'

# CDN request records with a 5xx status
vercel logs requests --query 'httpStatus >= 500'

# A specific window, as JSON Lines
vercel logs --since 2026-11-08T10:00:00Z --until 2026-11-08T11:00:00Z --json

Options worth knowing:

• --query (-q) takes a subset of Kibana Query Language: field:value, field:(a OR b), field:* for presence, field != value, numeric comparisons on request records, *text* contains, AND, OR, NOT, and parentheses. Wrap the whole query in single quotes, and double-quote values with spaces or colons.
• A bare word in a runtime query searches the message, case-insensitively.
• --since and --until take 1h, 30m, an ISO 8601 timestamp, or now. Searching a requestId older than 30 minutes needs a wider --since.
• --limit (-n) defaults to 100 and tops out at 10,000. --next <cursor> continues a larger result.
• --json prints one JSON object per line, and the last line is a summary. Pipe it to jq.
• --project, --deployment, and --environment narrow the scope.

The CLI does not stream. --follow is deprecated and now returns the query result with a warning. To follow logs live, use Live mode in the dashboard. Old flags such as --level, --search, and --branch are removed, and the command fails with the replacement if you pass them. For example, --level error becomes --query 'level:error'.

Forwarding Logs with a Log Drain

Log drains forward logs from your deployments to an HTTPS endpoint or a Marketplace integration as they are generated, which gives you retention beyond your plan's window and includes static requests. Log drains are available on Pro and Enterprise. Hobby and Pro Trial teams must upgrade.

To add one, go to Team Settings > Drains and add a new log drain, and choose Logs as the data type. Name the log drain and pick the projects. For logs you can set the log sources, the environments, and optional sampling rules that decide what share of traffic reaches the destination. Choose a custom endpoint and enter its URL. Each delivered record includes fields such as id, deploymentId, source, host, timestamp, and projectId. The source is one of build, edge, lambda, static, external, firewall, or redirect.

Vercel bills log drains by volume, measured as the uncompressed JSON size of each record. Sampling rules and narrow source selection reduce it.

Searching Vercel Logs with Sazabi

Sazabi, an AI-native observability and security platform, can receive Vercel logs through log drains. The simplest route is to connect your Vercel team under Settings > Log streams > Add source > Vercel with a team-scoped API token that has All Projects selected. Choose a project and the Logs tab in Add log stream, and Sazabi creates and maintains the log drain with JSON format set for you. Traces (as OpenTelemetry spans) and Web Analytics are available on the same path. Once logs flow, the latency spikes and crash loops detection guides describe what to watch for.

If you prefer to own it, create a log drain yourself, set the delivery format to JSON, and paste the Sazabi intake URL as the endpoint. That path covers logs only. Both routes need Pro or Enterprise. See the connect-your-account docs, the endpoint docs, and the Vercel integration page.