vercel-advanced-troubleshooting
Advanced troubleshooting guide for deep-dive Vercel deployment issues, logs, and edge network tracing.
Install
mkdir -p .claude/skills/vercel-advanced-troubleshooting && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/1215" && unzip -o skill.zip -d .claude/skills/vercel-advanced-troubleshooting && rm skill.zipInstalls to .claude/skills/vercel-advanced-troubleshooting
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Advanced debugging for hard-to-diagnose Vercel issues including coldKey capabilities
- →Trace single requests through Vercel's edge network to identify serving region and cache status
- →Instrument functions to measure cold start frequency and duration
- →Analyze function bundles to identify unexpectedly large dependencies
- →Debug region-specific issues by testing deployments from different geographic regions
- →Diagnose edge function crashes caused by Node.js API usage
- →Collect complete evidence bundles for Vercel support escalation
How it works
The skill provides commands and code snippets to trace requests, measure cold starts, analyze function bundles, and debug region-specific or edge function issues on Vercel. It also outlines a systematic isolation process.
Inputs & outputs
When to use vercel-advanced-troubleshooting
- →Debugging intermittent edge function errors
- →Investigating cold start performance issues
- →Tracing requests through Vercel's edge network
- →Preparing evidence for Vercel support
- →Inspecting deployment environment variables
About this skill
Vercel Advanced Troubleshooting
Overview
Diagnose hard-to-find Vercel issues: intermittent cold start failures, edge function crashes, region-specific behavior, function bundling problems, and serverless concurrency issues. Uses systematic isolation, request tracing, and Vercel-specific debugging techniques.
Prerequisites
- Vercel CLI with access to production logs
- Familiarity with
vercel-common-errors(standard debugging) curlandjqfor API inspection- Access to deployment inspection tools
Instructions
Step 1: Request-Level Tracing
# Trace a single request through Vercel's edge network
curl -v https://yourdomain.com/api/endpoint 2>&1 | grep -E "x-vercel|cf-ray|age|cache"
# Key headers to check:
# x-vercel-id: <region>::<function-id> — which region served the request
# x-vercel-cache: HIT/MISS/STALE — edge cache status
# x-vercel-execution-region: iad1 — function execution region
# age: 45 — seconds since edge cached the response
# x-matched-path: /api/endpoint — routing match result
Step 2: Cold Start Investigation
// Instrument cold start timing in your function
let coldStart = true;
const initTime = Date.now();
export default function handler(req, res) {
const isCold = coldStart;
coldStart = false;
const handlerStart = Date.now();
// ... your logic ...
res.setHeader('x-cold-start', String(isCold));
res.setHeader('x-init-duration', String(handlerStart - initTime));
res.json({
coldStart: isCold,
initDuration: isCold ? handlerStart - initTime : 0,
handlerDuration: Date.now() - handlerStart,
region: process.env.VERCEL_REGION,
});
}
# Measure cold start frequency over N requests
for i in $(seq 1 20); do
curl -s https://yourdomain.com/api/endpoint \
| jq '{coldStart, initDuration, region}'
sleep 2 # Wait between requests to allow isolate recycling
done
Step 3: Function Bundle Analysis
# Check what's being bundled into your function
vercel inspect https://my-app-xxx.vercel.app
# Check function sizes in the deployment
curl -s -H "Authorization: Bearer $VERCEL_TOKEN" \
"https://api.vercel.com/v13/deployments/dpl_xxx" \
| jq '.functions | to_entries[] | {path: .key, size: .value.size, regions: .value.regions}'
# Locally — check what @vercel/nft traces for a function
npx @vercel/nft print api/heavy-endpoint.ts 2>/dev/null | head -50
# Shows all files that will be bundled
# Find unexpectedly large dependencies
npx @vercel/nft print api/heavy-endpoint.ts 2>/dev/null \
| xargs -I {} du -sh {} 2>/dev/null | sort -rh | head -20
Step 4: Region-Specific Debugging
# Test from different regions to isolate geographic issues
# Use Vercel's deployment URL with region hints
for region in iad1 sfo1 cdg1 hnd1; do
echo "=== Region: $region ==="
curl -s -w "HTTP %{http_code} | Time: %{time_total}s\n" \
-H "x-vercel-ip-country: US" \
https://yourdomain.com/api/endpoint
done
# Check if the issue is region-dependent
# If latency varies wildly, check:
# 1. Function region vs database region (cross-region latency)
# 2. Edge middleware adding delay
# 3. External API calls from wrong region
Step 5: Edge Function Crash Debugging
// Edge functions crash silently on Node.js API usage
// Common crashes and their symptoms:
// Symptom: EDGE_FUNCTION_INVOCATION_FAILED with no error details
// Cause: Using Node.js Buffer, fs, crypto.createHash in edge runtime
// Diagnostic: check if imports are edge-compatible
export const config = { runtime: 'edge' };
export default function handler(request: Request) {
// This will crash silently:
// const hash = require('crypto').createHash('sha256');
// Use Web Crypto instead:
const encoder = new TextEncoder();
const data = encoder.encode('test');
const hashBuffer = await crypto.subtle.digest('SHA-256', data);
return Response.json({ ok: true });
}
# Check if a module is edge-compatible
npx edge-runtime --eval "import('your-module')" 2>&1
# Errors here mean the module won't work in edge functions
Step 6: Concurrency and Throttling Debug
# Check current function concurrency limits
curl -s -H "Authorization: Bearer $VERCEL_TOKEN" \
"https://api.vercel.com/v9/projects/my-app" \
| jq '{plan: .plan, concurrency: .concurrencyBucketName}'
# Hobby: 10 concurrent, Pro: 1000, Enterprise: 100000
# Load test to find throttling threshold
npx autocannon -c 50 -d 10 https://yourdomain.com/api/endpoint
# Watch for 429 responses indicating FUNCTION_THROTTLED
Step 7: Systematic Isolation
Issue persists? Isolate systematically:
1. Does it happen on preview deployments?
└── No → Production-only env var or domain issue
2. Does it happen with a minimal function?
└── No → Issue is in your code, not Vercel platform
3. Does it happen in all regions?
└── No → Region-specific infrastructure issue
4. Does it happen with edge runtime?
└── No → Node.js-specific issue (cold starts, module compat)
5. Does it happen without middleware?
└── No → Middleware is interfering — check matcher scope
6. Create minimal reproduction:
└── api/test.ts with only the failing behavior
└── Deploy standalone and test
Step 8: Vercel Support Escalation
# Collect comprehensive evidence
mkdir vercel-debug && cd vercel-debug
# Deployment details
vercel inspect https://yourdomain.com > inspect.txt
vercel logs https://yourdomain.com --limit=200 > logs.txt
# Request trace
curl -v https://yourdomain.com/api/failing-endpoint 2>&1 > curl-trace.txt
# Function analysis
curl -s -H "Authorization: Bearer $VERCEL_TOKEN" \
"https://api.vercel.com/v13/deployments/dpl_xxx" > deployment.json
# Platform status at time of issue
curl -s "https://www.vercel-status.com/api/v2/summary.json" > status.json
tar czf vercel-debug-$(date +%Y%m%d).tar.gz .
Output
- Request traced through Vercel's edge network with region and cache data
- Cold start frequency and duration quantified
- Function bundle analyzed for size issues
- Issue isolated to specific layer (edge, runtime, region, middleware)
- Evidence bundle ready for support escalation
Error Handling
| Symptom | Likely Cause | Debug Approach |
|---|---|---|
| Intermittent 500 errors | Cold start + unhandled async | Add global error handler, check init code |
| Latency spikes every ~15 min | Function isolate recycling (cold start) | Measure with x-cold-start header |
| Works in preview, fails in prod | Env var scope mismatch | Compare env vars across environments |
| EDGE_FUNCTION_INVOCATION_FAILED | Node.js API in edge runtime | Check imports for Node.js-only modules |
| Function works locally, fails deployed | Missing dependency or env var | Run vercel build locally, check output |
Resources
Next Steps
For load testing and scaling, see vercel-load-scale.
When not to use it
- →When standard troubleshooting methods are sufficient to resolve the issue
Prerequisites
Limitations
- →Edge functions crash silently on Node.js API usage
- →Function concurrency limits vary by Vercel plan
How it compares
This skill offers Vercel-specific commands and instrumentation for advanced debugging, providing concrete steps beyond generic troubleshooting guides.
Compared to similar skills
vercel-advanced-troubleshooting side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| vercel-advanced-troubleshooting (this skill) | 3 | 27d | Caution | Advanced |
| stac-troubleshooter | 1 | 6mo | Review | Intermediate |
| replit-incident-runbook | 0 | 27d | Caution | Intermediate |
| analyzing-logs | 14 | 27d | Review | Beginner |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by jeremylongshore
View all by jeremylongshore →You might also like
stac-troubleshooter
StacDev
Diagnose Stac build, deploy, rendering, caching, and navigation issues using repeatable checks. Use when users report stac build finding no screens, deploy mismatches, runtime unknown widget/action errors, cache staleness, or migration regressions.
replit-incident-runbook
jeremylongshore
Execute Replit incident response procedures with triage, mitigation, and postmortem. Use when responding to Replit-related outages, investigating errors, or running post-incident reviews for Replit integration failures. Trigger with phrases like "replit incident", "replit outage", "replit down", "replit on-call", "replit emergency", "replit broken".
analyzing-logs
jeremylongshore
Analyze application logs to detect performance issues, identify error patterns, and improve stability by extracting key insights.
sentry
openai
Use when the user asks to inspect Sentry issues or events, summarize recent production errors, or pull basic Sentry health data via the Sentry API; perform read-only queries with the bundled script and require `SENTRY_AUTH_TOKEN`.
obsidian-incident-runbook
jeremylongshore
Troubleshoot Obsidian plugin failures with systematic incident response. Use when plugins crash, data is corrupted, or users report critical issues with your Obsidian plugin. Trigger with phrases like "obsidian crash", "obsidian plugin broken", "obsidian incident", "debug obsidian failure", "obsidian emergency".
obsidian-observability
jeremylongshore
Set up comprehensive logging and monitoring for Obsidian plugins. Use when implementing debug logging, tracking plugin performance, or setting up error reporting for your Obsidian plugin. Trigger with phrases like "obsidian logging", "obsidian monitoring", "obsidian debug", "track obsidian plugin".