---
title: Runtime Logs
product: vercel
url: /docs/logs/runtime
type: reference
prerequisites:
  - /docs/logs
related:
  - /docs/deployments/logs
  - /docs/functions
  - /docs/deployments/environments
  - /docs/drains
  - /docs/functions/streaming-functions
summary: Learn how to search, inspect, and share your runtime logs with the Logs tab.
install_vercel_plugin: npx plugins add vercel/vercel-plugin
---

# Runtime Logs

> **🔒 Permissions Required**: Runtime Logs

The **Logs** section in the sidebar allows you to view, search, inspect, and [share](#log-sharing) your runtime logs without any third-party integration. You can also filter and group your [runtime logs](#what-are-runtime-logs) based on the relevant fields.

> **💡 Note:** You can only view runtime logs from the Logs tab. [Build
> logs](/docs/deployments/logs) can be accessed from the production deployment
> tile.

## What are runtime logs?

**Runtime logs** include all logs generated by [Vercel Functions](/docs/functions) invocations in both [preview](/docs/deployments/environments#preview-environment-pre-production) and [production](/docs/deployments/environments#production-environment) 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](#view-runtime-logs):

| **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](/docs/drains) |

## View runtime logs

To view runtime logs:

1. From the [dashboard](/dashboard), select the project that you wish to see the logs for
2. Open [**Logs**](https://vercel.com/d?to=%2F%5Bteam%5D%2F%5Bproject%5D%2Flogs\&title=Go+to+Logs) in the sidebar from your project overview
3. From here you can view, filter, and search through the runtime logs. Each log row shares [basic info](#log-details) about the request, like execution, domain name, HTTP status, function type, and RequestId.

![Image](https://vercel.com/front/docs/observability/request-log-overview-light.png?lightbox)

## 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](#limits). You can use the **Live mode** option to follow the logs in real-time.

![Image](https://vercel.com/front/docs/observability/request-live-logs-light.png?lightbox)

> **💡 Note:** All displayed dates and times are in UTC.

### 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](/docs/functions/streaming-functions) will always preserve the original intent:

| Source                          | [Streaming functions](/docs/functions/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 `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**

### 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](#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](/docs/functions) and [Routing Middleware](/docs/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](/docs/functions)**            | Logs generated from your Vercel Functions invocations. Log details include additional runtime Request Id details and other basic info |
| **[Routing Middleware](/docs/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](/docs/rewrites)                                                                                   |
| **Redirect**                                       | Logs generated from [redirect rules](/docs/redirects)                                                                                 |

### 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](#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`](/docs/headers/response-headers#x-vercel-cache) for the possible values.

### 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 deployment
- `preview` - 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.

> **💡 Note:** The matching is based on your IP address and User Agent. In some cases, this
> data may not be accurate, especially if you're using a VPN or proxy, or if
> other people in your network are using the same IP address and browser.

## 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.

| **Value**                        | **Description**                                                    |
| -------------------------------- | ------------------------------------------------------------------ |
| **[route](#route)**              | The route pattern defined in your code (e.g., `/blog/[slug]`)      |
| **[requestPath](#request-path)** | The actual URL path requested (e.g., `/blog/my-post`)              |
| **[requestType](#request-type)** | The request rendering type (api, ssr, isr, ppr, rsc, cron)         |
| **[level](#level)**              | The log level (warning, error, fatal)                              |
| **[resource](#resource)**        | The resource type (function, middleware, cache, rewrite, redirect) |
| **[host](#host)**                | Name of the [domain](/docs/domains) or subdomain                   |
| **[deployment](#deployment)**    | The deployment domain                                              |
| **deploymentId**                 | The unique identifier of your deployment                           |
| **[method](#request-method)**    | The request method (`GET`, `POST`, etc.)                           |
| **[cache](#cache)**              | The cache status (`HIT`, `MISS`, `STALE`, `PRERENDER`)             |
| **[status](#status-code)**       | HTTP status code                                                   |
| **requestId**                    | Unique identifier of the request                                   |
| **[environment](#environment)**  | The deployment environment (`production` or `preview`)             |
| **[branch](#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           |

> **💡 Note:** This  feature is limited to the
> `message` and `requestPath`
> field. Other fields can be filtered using the left sidebar or the filters in
> the search bar.

## 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 in the right sidebar:

| **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](/docs/domains) 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, see [`x-vercel-cache`](/docs/headers/response-headers#x-vercel-cache) for the possible values. |
| **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 including id, environment, and branch                                  |
| **Events**             | Timeline of events during the request with timing information                                                               |
| **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**.

Click this button, and it loads new log rows. The latest entries are added based on the selected filters.

## Log sharing

You can share a log entry with other [team members](/docs/rbac/managing-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                                   | 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 |

> **💡 Note:** The above limits are applied immediately when [upgrading
> plans](/docs/plans/hobby#upgrading-to-pro). For example, if you upgrade from
> [Hobby](/docs/plans/hobby) to [Pro](/docs/plans/pro-plan), you will have access to
> the Pro plan limits, and access historical logs for up to 1 day.


---

[View full sitemap](/docs/sitemap)
