We pointed a cost audit at our highest-spending Vercel project, expecting a bill worth shrinking. There wasn't one — team-wide usage came to $9.84 for the week, most of it the Pro subscription line itself. The audit found three production apps silently failing every deploy, and a health check calling all three fine.
The team's Vercel usage for the audited week came to $9.84, effectively — nothing metered outside the Pro plan's allotments, and $4.52 of that $9.84 is the flat subscription line, not usage at all. One project carried the one real number in the whole team: $1.39, driven by Fluid Compute memory and CPU plus Observability Events — the cost shape you'd expect from an always-polling status board. That's why the audit ran there specifically, against a linked project rather than a guess from bill totals.
Three low-effort findings came back: a pass-through middleware intercepting 97% of requests for nothing, a homepage re-running its full health-check fan-out on 1,538 of 1,539 requests because a 30-second cache was scoped per-instance instead of shared, and a cron route running a per-service health loop sequentially at p95 18 seconds — defended in its own source comment by a memory rationale an earlier Redis rewrite had already made obsolete. All three shipped in one commit after review.
The deploy carrying them failed. So had the docs-only deploy before it. That project's Vercel build credential was still the token revoked in an unrelated rotation three days earlier — invisible until then because the app rarely deploys. Checking with the real, replaced token instead of assuming the fix was isolated turned up the same dead credential twice more: a second app had been failing every deploy for four days straight, and a live re-run the next day caught a third — an AI-transparency scanner whose fix produced its first successful production deploy since the rotation.
A repo that cannot deploy is indistinguishable from a repo nobody is deploying — and nothing in our fleet was watching for the difference.
The same re-run exposed a defect in the tool meant to catch exactly this. Vercel records a skipped build as a CANCELED deployment, and our deploy-health check read the newest deployment regardless of status — so a project that had skipped its last five production builds in a row registered as broken, and the commit it was actually serving registered as stale. Fixed to judge health from the newest non-canceled deployment, and to read an all-skips window as intentionally quiet rather than dead. One docs-only site sat one cron cycle away from a false outage report.
The same cost audit, run next on a second project at the founder's request, found no spending problem there either — but its own cron, the route that checks anchored receipts for tampering, had been throwing unhandled 500s on 65% of its runs across more than ten deployments. Silent, because the route had no error boundary and its freshness marker only advanced on a success it was rarely reaching.
One red stayed after every fix landed: an orphaned Vercel project, unlinked to any repository, with two ERROR builds in its first minute and silence after — no environment variables, no domain, no git connection, no mention in any log or decision doc. Its birth timestamp put it inside an unrelated localization push four days earlier, one stray deploy run from an unlinked directory. A project that never once built successfully cannot be serving traffic, so deleting it cost nothing. With it gone, deploy-health across the whole team read green for the first time since the audit started.
This post was drafted by an AI system from Dekimu's public engineering record and published with automated checks, without per-post human editing.
← Back to blog