Runtime
Runtime Logs
The Logs section in the sidebar allows you to view, search, inspect, and share your runtime logs without any third-party integration. You can also filter and group your runtime logs based on the relevant fields.
Logs
Build
logs can be accessed from the production deployment
tile.
Copy page
Runtime logs include all logs generated by Vercel Functions invocations in both preview and production deployments. These log results provide information about the output for your functions as well as the console.log output.
With runtime logs:
- Logs are shown in realtime and grouped as per request.
- Each action of writing to standard output, such as using console.log, results in a separate log entry.
- The maximum number of logs is 256 lines per request
- Each of those logs can be up to 256 KB per line
- The sum of all log lines can be up to 1 MB per request
You can view the following log types in the Logs tab:
Log Type
Vercel Function Invocation
Yes
Yes
Available in Runtime Logs
We collaborate with trusted, high-quality partners to bring you reliable and top-notch products and services.
Static Request
To view runtime logs:
Routing Middleware Invocation
Only static request that serves cache; to get all static logs check Log Drains
- From the dashboard, select the project that you wish to see the logs for
- Open Logs in the sidebar from your project overview
- From here you can view, filter, and search through the runtime logs. Each log row shares basic info about the request, like execution, domain name, HTTP status, function type, and RequestId.
Layout to visualize the runtime logs.
Log filters
You can filter runtime logs based on a specific timeline. It can vary from the past hour, last 3 days, or a custom timespan depending on your account type. You can use the Live mode option to follow the logs in real-time.
You can use the following filters from the sidebar to get a refined search experience.
Layout to visualize the runtime logs in live mode.
Level
Source
stdout (e.g. console.log)
Streaming functions
info
Non-streaming Functions
info
stderr (e.g. console.error)
console.warn
error
warning
error
error
- Requests with a status code of 4xx are marked with Warning amber
- Requests with a status code of 5xx are marked with Error red
- All other individual log lines are considered Info
You can filter and analyze logs for one or more routes defined in your project. Route shows the pattern or template defined in your code (e.g., /blog/[slug]), unlike Request Path, which shows the specific path that was accessed (e.g., /blog/my-post). This is useful for analyzing traffic to a specific route regardless of the dynamic parameter values. The log output is generated for Vercel Functions and Routing Middleware.
You can view logs for one or more domains and subdomains attached to your team’s project. Alternatively, you can use the Search hosts... field to navigate to the desired host.
Like host and routes, you can filter your logs based on deployment URLs.
Using the resource filter, you can search for requests containing logs generated as a result of:
Resource
Description
Logs generated from your Vercel Functions invocations. Log details include additional runtime Request Id details and other basic info
Vercel Functions
Logs generated as a result of your Routing Middleware invocations
Rewrite
Redirect
Vercel CDN Cache
Logs generated from rewrite rules
Logs generated from proxy serving cache
Logs generated from redirect rules
You can filter your logs based on framework-defined mechanism or rendering strategy used such as API routes, Incremental Static Regeneration (ISR), and cron jobs.
You can filter your logs based on the request method used by a function such as GET or POST.
You can filter your logs based on the actual URL path requested by users. Request Path shows the specific path that was accessed (e.g., /blog/my-post), unlike Route, which shows the pattern (e.g., /blog/[slug]). This is useful for debugging specific requests or analyzing traffic to particular URLs.
You can filter your logs based on the cache behavior such as HIT or MISS. See x-vercel-cache for the possible values. For ISR and Partial Prerendering static shells that weren't a plain hit, the log details also show a Cache Reason explaining why the request missed, bypassed, or served stale.
Status Code
You can filter your logs based on the deployment environment:
You can filter your logs based on HTTP status codes. This is useful for finding requests that resulted in specific errors (like 404 or 500) or successful responses (200).
- production - Logs from your production deployment
- preview - Logs from preview deployments
You can filter your logs based on the git branch associated with the deployment. This is helpful when debugging issues on specific feature branches.
You can filter logs to only show requests made from your current browser by clicking the user button. This is helpful for debugging your own requests, especially when there's high traffic volume. The filter works by matching your IP address and User Agent against incoming requests.
Search log fields
You can use the main search field to filter logs by their messages. In the current search state, filtered log results are sorted chronologically, with the most recent first. Filtered values can also be searched from the main search bar.
deploymentId
The request rendering type (api, ssr, isr, ppr, rsc, cron)
The unique identifier of your deployment
The route pattern defined in your code (e.g., /blog/[slug])
Unique identifier of the request
The resource type (function, middleware, cache, rewrite, redirect)
The request method (GET, POST, etc.)
The deployment domain
requestId
The git branch associated with the deployment
The trace identifier for distributed tracing
The unique identifier for a specific function invocation
traceId
invocationId
HTTP status code
sessionId
Log details
Request Method
Info
Request Path
Description
Request path of the log
The HTTP method used (GET, POST, etc.)
Time
Status Code
Host
HTTP status code for the log message
Timestamp at which the log was recorded in UTC
Name of the domain or subdomain for which the log was generated
Request Id
Unique identifier of request created only for runtime logs
Request User Agent
Region
Name of the browser from which the request originated
Search parameters of the request path
The edge region where the request was processed
Firewall
Vercel Cache
Cache Reason
If request was allowed through firewall
The Vercel CDN Cache status, see x-vercel-cache for the possible values.
Cache Age
Why the response missed, bypassed, or served stale for static requests. See Cache Status and Reasons.
Cache TTL
PPR State
For ISR responses, how long ago the served cache entry was generated
Search Params
For ISR responses, how long the cache entry stays fresh before it revalidates
The PPR state for Partial Prerendering routes (Static, Partial, Dynamic)
Middleware
Function
Deployment
Events
Metadata about function execution including function name, location, runtime, duration, memory usage, and start type
Towards the end of the log results window is a button called Show New Logs. By default, it is set to display log results for the past 30 minutes.
Metadata about the deployment that produced the logs including id, environment, and branch
Timeline of events during the request with timing information
Outgoing Requests
Log Messages
Metadata about middleware execution such as location and duration
Click this button, and it loads new log rows. The latest entries are added based on the selected filters.
Sub-requests made during the function execution
The bottom panel shows a list of log messages produced in chronological order
Log sharing
You can share a log entry with other team members to view the particular log and context you are looking at. Click on the log you want to share, copy the current URL of your browser, and send it to team members through the medium of your choice.
Limits
Logs are streamed. Each log output can be up to 256KB, and each request can log up to 1MB of data in total, with a limit of 256 individual log lines per request. If you exceed the log entry limits, you can only query the most recent logs.
Runtime logs are stored with the following observability limits:
Plan
With Observability Plus, you can view up to 14 consecutive days of runtime logs within a 30-day window.
Hobby
Pro with Observability Plus
1 hour of logs
1 day of logs
30 days of logs
Pro
Enterprise
Enterprise with Observability Plus
3 days of logs
30 days of logs
Retention time
Cross-link map: Runtime Logs (/docs/logs/runtime)From the Vercel docs graph (built 2026-09-21T05:26:59.511Z), spanning vercel.com docs + KB, nextjs.org, ai-sdk.dev, and other Vercel documentation sites. Full graph as JSON: https://vercel.com/docs/graph.jsonSemantically closest pagesVercel Function Logs — Use runtime logs to debug and monitor your Vercel Functions.Logs — Use logs to find information on deployment builds, function executions, and more.AI Gateway Request Logs — Search, filter, and follow individual AI Gateway requests, inspect provider routing for one request, and export the resuAdd structured application logs to Vercel Functions — Learn how to add structured application logs to Vercel Functions to help troubleshoot function issues in real time.Enhanced Logs to search, inspect, and share runtime logsPrerequisitesLogs — Use logs to find information on deployment builds, function executions, and more.This page links to (15)Cache Status and Reasons — Understand the cache status and reason shown for each request in Vercel logs, and what causes a response to miss, bypassEnvironments — Environments are for developing locally, testing changes in a pre-production environment, and serving end-users in produDomains Overview — Learn the fundamentals of how domains, DNS, and nameservers work on Vercel.Working with Drains — Drains collect logs, traces, speed insights, and analytics from your applications. Forward observability data to customVercel Functions — Build API routes, webhooks, and agent request handlers with Vercel Functions, then test and debug them with Vercel CLI.Streaming — Learn how to stream responses from Vercel Functions.Incremental Static Regeneration \(ISR\) — ISR serves cached static pages while regenerating content in the background. Vercel\\Observability Plus — Learn about using Observability Plus and its limits.Partial Prerendering \(PPR\) — Partial Prerendering serves a cached static shell instantly, then renders and streams the dynamic parts of a page per reVercel Hobby Plan — Learn about the Hobby plan and how it compares to the Pro plan.Vercel Pro Plan — Learn about the Vercel Pro plan with credit-based billing, free viewer seats, and self-serve enterprise features for proManaging Team Members — Learn how to manage team members on Vercel, and how to assign roles to each member with role-based access control \(RBACRouting Middleware — Learn how you can use Routing Middleware, code that executes before a request is processed on a site, to provide speed aRedirects — Learn how to use redirects on Vercel to instruct Vercel's platform to redirect incoming requests to a new URL.Rewrites on Vercel — Learn how to use rewrites to send users to different URLs without modifying the visible URL.Pages that link here (31)By site: vercel-changelog (9) · vercel-kb (4) · vercel-docs (18)From vercel-changelog30-day runtime log retention, now available in Observability PlusAgents can now access runtime logs with Vercel's MCP serverCaching details now available in Runtime LogsFunction start type now available in Runtime LogsImproved streaming runtime logs exportsReferer now available in runtime logsRewrites and redirects now available in runtime logsRuntime logs now appear in the dashboard 6x fasterView specific error codes in runtime logsFrom vercel-kbAdd structured application logs to Vercel Functions — Learn how to add structured application logs to Vercel Functions to help troubleshoot function issues in real time.Migrate self-hosted Next.js and containers from AWS to Vercel — Migrate containers from AWS to Vercel: deploy with Dockerfile.vercel, keep RDS, S3, and SQS in AWS over OIDC, and cut ovTroubleshoot and optimize Active CPU usage on Fluid compute — Diagnose which routes drive Active CPU usage and learn to optimize it. Separate traffic growth from per-request CPU workBuild a Weather API on Vercel: Express, FastAPI, and Nitro — Build a weather API on Vercel with FastAPI, Express, or Nitro. Compare the three runtimes, add caching and ObservabilityFrom vercel-docsCache Status and Reasons — Understand the cache status and reason shown for each request in Vercel logs, and what causes a response to miss, bypassVercel CDN Cache — Learn how Vercel's CDN cache stores your content across a global network to reduce latency and origin load.Managing Cron Jobs — Learn how to manage Cron Jobs effectively in Vercel. Explore cron job duration, error handling, deployments, concurrencyIntegrate flags with Vercel Web Analytics — Learn how to tag your page views and custom events with feature flagsCreate React App on Vercel — Deploy Create React App projects to Vercel and add Preview Deployments, Web Analytics, Speed Insights, and ObservabilityConcurrency scaling — Learn how Vercel automatically scales your functions to handle traffic surges.Vercel Function Logs — Use runtime logs to debug and monitor your Vercel Functions.Response headers — Learn about the response headers sent to each Vercel deployment and how to use them to process responses before sendingLimits — Look up account limits, usage summaries, rate limits, and resource constraints for every Vercel plan.Logs — Use logs to find information on deployment builds, function executions, and more.Account Plans on Vercel — Learn about the different plans available on Vercel.Vercel Enterprise Plan — Learn about the Enterprise plan for Vercel, including features, pricing, and more.Vercel Hobby Plan — Learn about the Hobby plan and how it compares to the Pro plan.Transferring a project — Learn how to transfer a project between Vercel teams.Routing — Learn how Vercel's CDN routes requests through firewall, project routes, and deployment routes before reaching your applShared Responsibility Model — Discover the essentials of our Shared Responsibility Model, outlining the key roles and responsibilities for customers,Tracing — Learn how to trace your application to understand performance and infrastructure details.Session tracing — Learn how to trace your sessions to understand performance and infrastructure details.
