The Usage tab on the Dashboard provides detailed insight into the actual resource usage of your projects.
Usage tab on the dashboard.
Gain insight into how well your projects are performing with the Usage page, and then take the necessary actions for improvements.
In the header, you can filter the usage by a specific period of time, project, and function path.
Filter usage by date, project and function.
The sections showing your usage include: Networking, Serverless Functions, Edge Functions, Edge Middleware, Builds, Artifacts, Analytics, and Image Optimizations. In each section, you can see related charts showing detailed usage in different dimensions.
The sections showing your usage.
Top Paths displays the paths that consume the most resources on your Team. This functionality allows you to optimize your website by providing enhanced insights about assets, invocations, and requests consuming the most data over time.
With Top Paths, you can apply filters to query a particular date range or a specific Project. In compact view, you can see the top 10 paths consuming the most bandwidth on your projects. Clicking the "explore" button expands the section to a full page, allowing your Team to see more paths as well as providing the ability to download a CSV file and share the view with other team members. The retention limit for querying data is 90 days.
View Top Paths that consume most of the bandwidth across your projects.
Top Paths lets you view the top resources by:
request_path: The exact path that was requested.source_path: The mapping of the path that was requested.
Here's an example showing the difference between the two path types. Let's say you have an application with a dynamic route /blog/[slug]. If a user makes a request to /blog/100, the path types would be:
request_path:/blog/100source_path:/blog/[slug]
Usage Top Paths and the Monitoring tab both help you visualize the consumed resources of your Team's projects. You can click any of the usage paths in Bandwidth, Execution Time, Invocations, and Requests to navigate the Monitoring tab query editor and gain insights on that particular path.
Bandwidth is the amount of data your Deployments have sent or received. This chart includes traffic for both Preview and Production Deployments.
The Bandwidth graph below shows the amount of data your Deployments have sent or received.
The usage chart grouped by ratio.
You can also group usage by your top four projects.
The usage chart grouped by projects.
The total traffic of your projects is the sum of the Outgoing and Incoming bandwidth.
- Outgoing: Outgoing bandwidth measures the amount of data that your Deployments have sent to your users. All the responses from the Edge Network and Serverless Functions are collected as Outgoing bandwidth.
- Incoming: Incoming bandwidth measures the amount of data that your Deployments have received from your users.
An example of incoming bandwidth would be page views that are requested by the browser. All the requests sent to the Edge Network and Serverless Functions are collected as incoming bandwidth.
Incoming bandwidth is usually much smaller than outgoing bandwidth for website projects.
The number of Cached and Uncached requests that your Deployments have received.
Similar to Bandwidth, the Requests chart includes requests for both Preview and Production Deployments.
- Cached: If a request is served by the Vercel Edge Network cache, it's considered to be a cached request
- Uncached: If a request isn't served by the cache and hits the Origin instead, it is not cached. In addition, under some specific conditions the request can never be cached. These numbers are considered as Uncached requests
As a Vercel customer, you will be billed for both Cached and Uncached requests.
The number of times your Serverless Functions received a request. This does not include Cache Hits.
- Successfully: All invocations that finished successfully by running your Serverless Function
- Errored: All invocations where your Serverless Function failed (returned an HTTP 5xx status code) before it finished or times where your Function couldn't be invoked due to an unexpected error
- Timeout: If your Serverless Function was invoked but didn't return before it reached its execution timeout, it'll be counted as a timeout
When using Incremental Static Regeneration with Next.js, both the revalidate option for getStaticProps and fallback for getStaticPaths will result in a Function invocation.
The amount of time your Serverless Functions have spent computing responses to the requests they’ve received. The value is given in GB-Hours, which is the memory allocated for each Function in GB, multiplied by the time in hours they were running. By default, Functions are allocated 1GB of memory, but can be configured to use more.
- Completed: The execution time for Functions that were executed and finished successfully
- Errored: The execution time for Functions that were executed but failed (returned an HTTP 5xx status code). The value represents the GB-Hours from when they started until they failed
- Timeout: The execution time for Functions that were executed but didn't finish before they reached their execution timeout
For example:
- If a function is configured to use 1GB of memory and executes for 1 second, this would be billed at 1 GB-s, requiring 3,600 executions in order to reach a full GB-Hr
- If a function is configured to use 3GB of memory that executes for 1 second, this would be billed at 3 GB-s, requiring 1,200 executions to reach a full GB-Hr
The majority of Serverless Functions will execute for a much shorter duration with a minimal billed duration of 1ms.
The number of times that a request to your Functions could not be served because the concurrency limit was hit.
The number of times your Edge Functions received a request.
- Successfully: All invocations that finished successfully by running an Edge Function
- Errored: All invocations where an Edge Function failed (returned an HTTP 5xx status code) before it finished or times where your Function couldn't be invoked due to an unexpected error
- Timeout: If an Edge Function was invoked but didn't return before it reached its maximum initial response time, it'll be counted as a timeout
The number of execution units that your Edge Functions have used.
Execution Units is shown for all Edge Functions in all projects within your Team.
The time your Edge Functions have spent computing responses to requests.
CPU time can be viewed in two ways:
- Average - This shows the average time for computation across all projects using Edge Functions within your Team. You can hover over the line to see an average for each project on any chosen day.
- Project - This shows the total time each project using Edge Functions within your Team has spent computing responses to requests.
The number of times your Middleware received a request.
- Successfully: All invocations that finished successfully by running your Middleware
- Errored: All invocations where your Middleware failed (returned an HTTP 5xx status code) before it finished or times where your Middleware couldn't be invoked due to an unexpected error
- Timeout: If your Middleware was invoked but didn't return before it reached its maximum initial response time, it'll be counted as a timeout
The time your Middleware has spent computing responses to requests.
CPU time can be viewed in two ways:
- Average - This shows the average time for computation across all projects using Middleware within your Team. You can hover over the line to see an average for each project on any chosen day. The Fair Use Policy denotes an average CPU time limit of 50ms/invocation within a one hour period across all of your Team's projects.
- Project - This shows the total time each project using Middleware within your Team has spent computing responses to requests.
The amount of time that your Deployments have spent being queued or building.
- Build Time: The amount of time it took your Deployments to get from the building state to a final state
- Queued Time: The amount of time it took your Deployments to get from creation to building
How many times a build was issued for one of your Deployments.
- Completed: All builds that successfully completed or were cancelled
- Errored: All builds that failed or timed out
Artifacts are blobs of data or files that are uploaded and downloaded using the Vercel Remote Cache API. Uploaded artifacts can be downloaded during your build and by your Team Members.
During deployment on Vercel, your build has access to an environment variable VERCEL_ARTIFACTS_TOKEN that can be used as the Bearer token for requests to the Remote Cache API. Otherwise, you may use a Vercel Access Token for authorization.
Uploaded artifacts on Vercel automatically expire after 7 days.
Artifacts are annotated with a task duration, which is the time required to generate the artifact. The Time Saved is the sum of that task duration for each artifact multiplied by the number of times that artifact was reused from a cache.
- Remote Cache: The time saved by using artifacts cached on the Vercel Remote Cache API.
- Local Cache: The time saved by using artifacts cached on your local filesystem cache.
- Uploaded: The number of uploaded artifacts using the Remote Cache API.
- Downloaded: The number of downloaded artifacts using the Remote Cache API.
- Uploaded: The size of uploaded artifacts using the Remote Cache API.
- Downloaded: The size of downloaded artifacts using the Remote Cache API.
Multiple uploads or downloads of the same artifact are counted as distinct events when calculating these sizes.
The number of individual points of data that were reported from your visitor’s browsers for the Speed Insights feature.
The number of source images. A source image is the original, unaltered image determined by the src prop. If the same source image is used multiple times with different transformations, it is only counted once for the current billing period.
See the relevant docs for more information on billing and limits. For tips on ensuring efficent use of Image Optimization, see Managing Image Optimization costs.