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.