# Vercel Production Cost Review > Audit a defined Vercel production cost question using billing and usage evidence, then recommend or verify bounded remediations. Use only when the user explicitly asks for a Vercel cost review, unexpected bill or usage spike investigation, Fast Data Transfer analysis, or post-remediation savings verification. Do not trigger for ordinary Vercel deployment, generic performance work, routine caching changes, or optimizing one route without a cost question. - Skill: `swyxio/vercel-production-cost-review` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add swyxio/vercel-production-cost-review` - Raw SKILL.md: https://api.skillmd.com/api/skills/swyxio/vercel-production-cost-review/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Security - Author: swyxio (https://skillmd.com/u/swyxio) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/swyxio/vercel-production-cost-review --- # Vercel Production Cost Review Use this skill to turn Vercel usage into an evidence-backed remediation plan. Diagnose before changing code or firewall rules. ## Counterweight: material cost before optimization - Start from the bill, usage delta, review window, and financial materiality. Do not optimize hypothetical or trivial spend. - Scope only the projects, zones, routes, and metrics needed to explain the cost question. Do not inventory every production surface by default. - Prefer Vercel billing and usage facts over proxy metrics. State plan or retention limits instead of manufacturing certainty. - Rank causes and investigate the smallest set that explains most of the material change. - Do not add telemetry, WAF rules, rate limits, cache layers, payload variants, asset pipelines, or architectural changes without evidence they address a material driver. - Prefer configuration or deletion over code. Preserve legitimate traffic and protocol behavior. - Separate diagnosis from remediation. Code edits, firewall publication, project configuration, deployment, and follow-up monitoring require the active request to authorize them. - A cost review may correctly conclude that current spend is expected or that no remediation is worth its complexity. ## Workflow 1. **Establish scope and baseline** - Confirm the relevant team, projects or zones, and review window. - Capture current total spend/usage and the previous comparable period. - Inventory Vercel project links and Root Directory settings before using project-scoped CLI commands. 2. **Rank cost drivers** - Query usage by project, route/path, method, status, cache result, region, and bot dimensions when available. - Start with Fast Data Transfer incoming, outgoing, and total bytes plus request count. - Separate shared-domain paths from their owning Vercel projects/zones. - If detailed metrics require Observability Plus, use the dashboard export, runtime-log grouping, response probes, and project/deployment APIs as fallback evidence. 3. **Diagnose before fixing** - Consider at least: abusive polling/scraping, oversized responses, oversized public assets, missing browser caching, missing CDN caching, dynamic/POST responses, duplicate middleware/function work, Next data payloads, and stale project configuration. - Distill to the 1–2 most likely causes. - Add temporary privacy-safe request logs only when the active request includes instrumentation and cheaper provider evidence is insufficient. - Measure representative response headers and compressed/uncompressed sizes. 4. **Choose the right remediation** - **Abuse:** Vercel Firewall deny/challenge/rate-limit at the edge; preserve legitimate protocol methods. - **Payload size:** paginate, omit heavy fields by default, compact JSON, compress, and offer explicit opt-ins for detail. - **Assets:** resize/re-encode large images and fonts; preserve stable URLs where compatibility matters. - **Browser transfer:** set a safe `max-age`; use content hashes plus `immutable` for versioned assets. - **Origin work:** use `s-maxage`, `stale-while-revalidate`, ISR, or Vercel CDN cache controls. - **Architecture:** avoid shipping large page props or `/_next/data` payloads when details can load on demand. 5. **Apply safely** - Treat WAF publication, production config changes, and deploys as external mutations requiring authorization. - Stage and inspect firewall rules before publishing. - Preserve unrelated working-tree changes. - Test route patterns with a production build before deploying. - Deploy only explicitly authorized owning projects and affected zones. 6. **Verify impact** - Smoke critical routes, metadata, API/MCP protocol calls, redirects, and zone ownership. - Verify expected status, `Cache-Control`, `x-vercel-cache`, content encoding, and response size. - Re-query traffic after enough time for a useful sample; compare request rate and bytes/request with baseline. - Record incomplete evidence, plan limits, and any frozen zone that could not redeploy. ## Critical distinctions - A CDN `HIT` reduces origin compute and latency, but Fast Data Transfer still counts bytes sent from Vercel to the client. - Browser caching, smaller payloads, and blocking unwanted traffic reduce outgoing transfer; CDN caching alone may not. - Vercel may consume or strip `s-maxage` from the client-visible `Cache-Control` header. Use `x-vercel-cache` and targeted CDN headers to verify edge behavior. - Static Next.js chunks are usually immutable already. A hot chunk can still be expensive if it is very large or repeatedly fetched by new clients. - POST responses are normally not safely CDN-cacheable because the request body affects the result. - Runtime logs can contain both middleware and function entries for one request. Do not treat raw log rows as unique requests without checking source. ## Optional cadence **Weekly spike review** - Compare seven-day totals and top paths with the prior week. - Investigate new routes, sudden request-rate changes, and bytes/request regressions. - Confirm active firewall mitigations and recent deploy impact. **Monthly broader review** - Review the production projects or zones the user places in scope. - Audit large public assets, Next data/page payloads, API defaults, cache headers, project roots, and archived-site TTLs. - Update the baseline and prioritized savings backlog. ## Output Report: 1. Period, team, projects, and evidence limitations. 2. Top drivers with requests, incoming bytes, outgoing bytes, total bytes, and bytes/request. 3. Likely cause for each material driver. 4. Actions taken versus recommended, with risk and expected savings. 5. Verification results and follow-up measurement time. For the repeatable audit checklist and command patterns, read [checklist.md](references/checklist.md).