Optimize Vercel Deployments with Observability

Vercel Optimize runs an observability-first audit of a deployed Vercel app for cost and performance issues, starting from production metrics rather than a repo-wide code scan, and only investigating source files once a deterministic gate points to a specific route, file, or project setting.

Use this when auditing a deployed Vercel app for cost and performance issues using metrics, project config, code scans, and version-aware recommendations. It requires Vercel CLI v53+ with vercel metrics/usage/contract/api, an authenticated CLI session, a linked app directory with a resolved org/team/user scope, Node.js 20+, and Observability Plus for route-level metric-backed recommendations; auth tokens must never be typed into shell commands that could be echoed in chat. Framework support varies: Next.js App Router, Pages Router, and SvelteKit are fully supported, Nuxt is supported with fewer framework-specific recommendations, Astro is limited, and Hono/Remix/unknown frameworks are blocked by default unless the user explicitly accepts a limited platform/code-only audit.

A fresh run directory is created per audit; nothing is reused across runs. The pipeline: collect and merge Vercel production signals with a codebase scan into signals.json, resolving a single CLI scope shared by every subsequent Vercel command so metrics and project config come from the same account; check for blockers such as an unsupported framework, unresolved project/team scope, no traffic, Observability Plus not enabled or quota-exhausted, or an unlinked/forbidden project, each with a specific required prompt or stop condition, never silently falling back to code-only mode without asking; gate investigation candidates with a deterministic script into code-scope, platform-scope, and gated-but-still-reported groups, defaulting to a 6-candidate budget with a diversity guardrail; deep-dive each candidate and reconcile disproven ones into observations, such as a metric mismatch or deployment regression, before any source is read; generate one investigation brief per candidate and fan out to sub-agents for 3+ briefs, each reading only the files named in its brief plus route-local imports and abstaining rather than widening scope if it needs a repo-wide grep; verify every recommendation's claims, cited files, line numbers, and framework-version fit, regenerating failed ones against the specific check they failed; and render the final customer-facing report and print it verbatim with no added summary, debug notes, or raw counts.

Every recommendation must trace to a candidate or verified finding, cite observed metric evidence and verified file/line references, use precise observed numbers rather than invented ones, and describe cost impact only in magnitude terms, never a customer-facing dollar figure. Hard rules include never recommending duration reductions for Vercel Workflow runtime endpoints, never framing long-lived streaming/SSE routes' wall-clock duration as a problem without evidence of avoidable pre-first-byte work, and never suggesting caching for auth-sensitive, error, or otherwise unsafe-to-cache responses without proof they're safe. Scanner findings are supplementary and dropped unless traffic-independent, such as middleware matchers or build settings, or backed by route-level traffic evidence. Customer-facing copy uses fixed terms like "recommendations ready" or "not investigated in this run" and explicitly avoids internal jargon like "sub-agent," "gate," or "quality score," with prewritten failure messages for no-traffic, missing-Observability-Plus, unlinked-project, and failed-route-mapping scenarios.

Teams auditing a live Vercel deployment for cost and performance issues who want recommendations grounded in real production metrics and verified source evidence rather than generic best-practice advice, with strict guardrails against scope creep, unverifiable claims, and customer-facing implementation leakage.