Observability
Deploying is the easy part. Knowing what's happening after you deploy is where observability comes in. Vercel gives you several tools to monitor performance and usage, from a high-level overview down to granular queries.
The observability overview
Start here for the big picture. The overview page shows four key metrics:
- Edge Requests — traffic to your static and dynamic routes through Vercel's global network
- Fast Data Transfer — how much data moves from Vercel's CDN to the client
- Functions — signals around function usage, execution time, failures, and timeouts
- Compute — average function runtime across your project
Click into any of these to drill down.
Edge Requests in detail
The Edge Requests view breaks traffic down by route. A few investigation patterns to keep in mind:
- Sort by request volume to find your highest-traffic routes
- Sort by cache hit rate to spot routes that aren't caching as well as expected
- Check verified bot traffic to understand how much automated traffic is affecting your usage
Click into a specific route for deeper detail. Average response size can reveal unoptimized assets or oversized payloads. Time to first byte (TTFB) is a good starting point when users report that a route feels slow.
Query
When the built-in breakdowns aren't enough, Query lets you build custom investigations. The flow is:
- Choose a data source (Edge Requests, function invocations, image transformations)
- Choose a metric (like time to first byte)
- Group by a dimension (like route) to compare
You can adjust the time frame to compare periods and spot when a regression started. Save queries you'll reuse into notebooks for future investigations.
Alerts
Rather than checking dashboards manually, alerts notify you when something is off. By default, you can subscribe to usage anomalies and error anomalies. Notifications go to email, Slack, or a webhook.
A practical starting point: set up at least one error anomaly alert so you find out quickly if error rates spike in production.
External APIs
If your app depends on upstream services, slow responses might not be your fault. The External APIs view shows requests your functions make to third-party services, sortable by request volume, P75 latency, and error rate.
Recap
- Start with the overview for a high-level picture of traffic, data transfer, functions, and compute
- Drill into Edge Requests for route-level detail on cache hit rates, response sizes, and TTFB
- Use Query with percentile metrics like P90 for deeper performance analysis
- Enable alerts so you're notified proactively when something breaks
- Check External APIs when the bottleneck is upstream, not in your own code
Follow up docs
Was this helpful?