Debugging Slow Vercel Functions

Use this guide to diagnose and fix slow Vercel Functions. You'll identify which functions are slow, measure where the time is spent, and verify that your optimization works before shipping to production.

Use this block when you already know what you're doing and want the full command sequence. Use the steps below for context and checks.

# 1. Identify slow functions from production logs
vercel logs --environment production --source serverless --since 1h --json \
  | jq 'select(.statusCode != null) | {path: .path, statusCode: .statusCode}'
 
# 2. Measure endpoint timing (server processing = time in your function)
vercel httpstat /api/slow-endpoint
 
# 3. Check function configuration (memory, region, max duration)
vercel inspect <deployment-url>
 
# IF server processing time is high, check external API latency:
vercel logs --environment production --query "timeout" --since 1h --expand
vercel logs --environment production --query "ECONNREFUSED" --since 1h --expand
 
# IF first request is slow but subsequent requests are fast, check cold starts:
vercel httpstat /api/slow-endpoint    # first request (potentially cold)
vercel httpstat /api/slow-endpoint    # second request (warm)
vercel httpstat /api/slow-endpoint    # third request (warm)
 
# 4. After optimizing, deploy a preview and measure
vercel deploy
vercel httpstat /api/slow-endpoint --deployment <preview-url>
vercel curl /api/slow-endpoint --deployment <preview-url>
 
# 5. Ship to production and monitor
vercel deploy --prod
vercel logs --environment production --source serverless --since 5m

Start by checking your production logs for slow requests. Filter for your function routes and look for high latency:

vercel logs --environment production --source serverless --since 1h --json \
  | jq 'select(.statusCode != null) | {path: .path, statusCode: .statusCode}'

To see the full log output with expanded messages:

vercel logs --environment production --source serverless --since 1h --expand

The --source serverless filter limits results to Vercel Functions, excluding static assets and edge requests.

Use vercel httpstat to get a detailed timing breakdown for a specific endpoint. This shows DNS lookup, TCP connection, TLS handshake, server processing, and content transfer times:

vercel httpstat /api/slow-endpoint

The server processing time is the portion spent inside your function. If this is the largest number, the issue is in your function code or its dependencies (database queries, external API calls).

To test against a specific deployment:

vercel httpstat /api/slow-endpoint --deployment <deployment-url>

Inspect the current deployment to see what configuration your functions are running with:

vercel inspect <deployment-url>

Key things to check:

• Memory: Functions with too little memory get CPU-throttled. If your function does heavy computation, increasing memory from the default 1024 MB can reduce execution time
• Region: If your function is far from your data source, every database query adds latency. Check that your function region matches your database region
• Max duration: If your function is hitting the maximum duration limit, it may be getting terminated before completing

See configuring functions for how to adjust these settings.

Slow functions are often caused by slow external API calls rather than slow function code. Check for timeout-related errors:

vercel logs --environment production --query "timeout" --since 1h --expand

vercel logs --environment production --query "ECONNREFUSED" --since 1h --expand

If you find timeout or connection errors, the issue is likely with an upstream dependency rather than your function itself.

Cold starts happen when a new function instance needs to be initialized. Look for patterns where the first request after a period of inactivity is slow, but subsequent requests are fast.

Run multiple requests to the same endpoint and compare timing:

vercel httpstat /api/slow-endpoint
vercel httpstat /api/slow-endpoint
vercel httpstat /api/slow-endpoint

If the first request is significantly slower than the following ones, cold starts are the issue. Common fixes include:

• Reducing the function bundle size by removing unused dependencies
• Moving expensive initialization outside the request handler
• Increasing the memory allocation (which also increases CPU)

Based on what you found, apply the fix. Common optimizations for slow functions include:

• Adding caching for database queries or external API responses
• Moving the function region closer to the data source
• Increasing function memory to reduce CPU throttling
• Reducing bundle size to speed up cold starts
• Adding connection pooling for database connections
• Parallelizing independent async operations with Promise.all

Deploy the optimized code as a preview:

vercel deploy

Run the same timing analysis against the preview to compare before and after:

vercel httpstat /api/slow-endpoint --deployment <preview-url>

Also verify that the function still returns correct responses:

vercel curl /api/slow-endpoint --deployment <preview-url>

Once you've confirmed the improvement, deploy to production:

vercel deploy --prod

Monitor the production logs after deploying to confirm the latency improvement holds under real traffic:

vercel logs --environment production --source serverless --since 5m

• vercel logs
• vercel httpstat
• vercel inspect
• Configuring functions
• Observability
• Debugging production 500 errors