Runtime Logs
Runtime Logs
Runtime Logs are available on all plans.
The Logs section 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.
You can only view runtime logs from the Logs tab. Build logs can be accessed from the production deployment tile.
What are runtime logs?
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
Available log types
You can view the following log types in the Logs tab:
| Log Type | Available in Runtime Logs |
|---|---|
| Vercel Function Invocation | Yes |
| Routing Middleware Invocation | Yes |
| Static Request | Only static request that serves cache; to get all static logs check Log Drains |
View runtime logs
To view runtime logs:
- 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 use the following filters from the sidebar to get a refined search experience.
Timeline
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.
Layout to visualize the runtime logs in live mode.
Level
You can filter requests that contain Warning, Error, or Fatal logs. A request can contain multiple types of logs at the same time. Streaming functions will always preserve the original intent:
| Source | Streaming functions | Non-streaming Functions |
|---|---|---|
stdout (e.g. console.log) |
info |
info |
stderr (e.g. console.error) |
error |
error |
console.warn |
warning |
error |
Additionally:
- Requests with a status code of
4xxare marked with Warning amber - Requests with a status code of
5xxare marked with Error red - All other individual log lines are considered Info
Route
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.
Host
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.
Deployment
Like host and routes, you can filter your logs based on deployment URLs.
Resource
Using the resource filter, you can search for requests containing logs generated as a result of:
| Resource | Description |
|---|---|
| Vercel Functions | Logs generated from your Vercel Functions invocations. Log details include additional runtime Request Id details and other basic info |
| Routing Middleware | Logs generated as a result of your Routing Middleware invocations |
| Vercel CDN Cache | Logs generated from proxy serving cache |
| Rewrite | Logs generated from rewrite rules |
| Redirect | Logs generated from redirect rules |
Request Type
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.
Request Method
You can filter your logs based on the request method used by a function such as GET or POST.
Request Path
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.
Cache
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 HTTP status codes. This is useful for finding requests that resulted in specific errors (like 404 or 500) or successful responses (200).
Environment
You can filter your logs based on the deployment environment:
production- Logs from your production deploymentpreview- Logs from preview deployments
Branch
You can filter your logs based on the git branch associated with the deployment. This is helpful when debugging issues on specific feature branches.
Logs from your browser
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.
| Value | Description |
|---|---|
| route | The route pattern defined in your code (e.g., /blog/[slug]) |
| requestPath | The actual URL path requested (e.g., /blog/my-post) |
| requestType | The request rendering type (api, ssr, isr, ppr, rsc, cron) |
| level | The log level (warning, error, fatal) |
| resource | The resource type (function, middleware, cache, rewrite, redirect) |
| host | Name of the domain or subdomain |
| deployment | The deployment domain |
| deploymentId | The unique identifier of your deployment |
| method | The request method (GET, POST, etc.) |
| cache | The cache status (HIT, MISS, STALE, PRERENDER) |
| status | HTTP status code |
| requestId | Unique identifier of the request |
| environment | The deployment environment (production or preview) |
| branch | The git branch associated with the deployment |
| sessionId | The session identifier for grouping related requests |
| traceId | The trace identifier for distributed tracing |
| invocationId | The unique identifier for a specific function invocation |
Log details
You can view details for each request to analyze and improve your debugging experience. When you click a log from the list, the following details appear:
| Info | Description |
|---|---|
| Request Method | The HTTP method used (GET, POST, etc.) |
| Request Path | Request path of the log |
| Time | Timestamp at which the log was recorded in UTC |
| Status Code | HTTP status code for the log message |
| Host | 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 | Name of the browser from which the request originated |
| Search Params | Search parameters of the request path |
| Region | The edge region where the request was processed |
| Firewall | If request was allowed through firewall |
| Vercel Cache | The Vercel CDN Cache status |
| Cache Reason | Why the response missed, bypassed, or served stale |
| Cache Age | For ISR responses, how long ago the served cache entry was generated |
| Cache TTL | For ISR responses, how long the cache entry stays fresh before it revalidates |
| PPR State | The PPR state for Partial Prerendering routes |
| Middleware | Metadata about middleware execution such as location and duration |
| Function | Metadata about function execution including function name, location, runtime, duration, memory usage, and start type |
| Deployment | Metadata about the deployment that produced the logs |
| Events | Timeline of events during the request |
| Outgoing Requests | Sub-requests made during the function execution |
| Log Messages | The bottom panel shows a list of log messages produced in chronological order |
Show additional logs
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.
Log sharing
You can share a log entry with other team members. Click on the log you want to share, copy the current URL of your browser, and send it to team members.
Limits
Logs are streamed. Each log output can be up to 256KB. The limits are:
| Plan | Retention time |
|---|---|
| Hobby | 1 hour of logs |
| Pro | 1 day of logs |
| Pro with Observability Plus | 30 days of logs |
| Enterprise | 3 days of logs |
| Enterprise with Observability Plus | 30 days of logs |
With Observability Plus, you can view up to 14 consecutive days of runtime logs within a 30-day window.
The above limits are applied immediately when upgrading plans.