Vercel's Spending Cap Doesn't Cap Your Spending: The Bandwidth Math Behind $23K Bills

A developer's blog post that went viral on Hacker News in 2026 described waking up to a $23,000 Vercel invoice. A botnet had pointed a few hundred megabits per second of requests at the heaviest assets on the site for a long weekend — call it 10-plus terabytes of attack traffic — and Vercel billed every byte of it at the standard rate, because nothing in the platform's default configuration distinguishes a DDoS attack from a viral launch. A college student reported the same failure mode at $3,200. Searching "Vercel bill shock" turns up a small genre of these stories, and they all end the same way: "I found out when the invoice arrived."

The natural response is "doesn't Vercel have a spending cap for exactly this?" It does — Vercel calls it Spend Management, and it's been available since 2024. But reading the feature's own documentation closely reveals it isn't a ceiling in the sense most people mean the word. It's opt-in, it checks usage every few minutes instead of continuously, and when it fires, it doesn't throttle or block the overage — it takes your entire production deployment offline. Understanding exactly how it works, and exactly what Vercel's usage-based pricing actually charges per gigabyte and per function call, is the difference between budgeting for a self-hosted migration with real numbers and guessing.

The Cap Is a Kill Switch, Not a Ceiling​

Vercel's own Spend Management docs are explicit about three limitations that matter more than the feature's existence:

• It's off by default. "Setting a spend amount does not automatically stop usage. If you want to pause all your projects at a certain amount, you must enable the option." A team that never visits Billing settings has no cap at all — which is exactly the state most of the bill-shock stories describe.
• It's not real-time. "Vercel checks your metered resource usage often... this check happens every few minutes. Because these checks are not continuous, notifications, webhooks, and project pausing can trigger several minutes after you cross your spend amount." A traffic spike that runs hot for ten minutes can blow past a configured cap before the system reacts at all.
• It pauses everything, not the overage. When the threshold is hit, Vercel "automatically pauses the production deployment for all projects on your team" — every visitor sees a 503 DEPLOYMENT_PAUSED error, and projects "won't automatically unpause if you increase the spend amount; you must resume each project manually." The cap doesn't cost-limit your app; it turns it off, team-wide, until someone notices and clicks resume on each project by hand.

That's a legitimate circuit breaker for a runaway bill, but it's a different tool than the one the word "cap" implies. A hard ceiling on a fixed-capacity server means you simply can't spend past what you provisioned — there's no invoice to overshoot in the first place. A pausing feature bolted onto a live meter means the meter runs, possibly for several minutes past your limit, and then your product goes dark for every real customer along with whatever traffic tripped the threshold. Teams that enable it are trading bill shock for outage risk, not eliminating either one.

What the Meter Actually Charges​

Vercel bills Vercel Functions on three simultaneous axes — Active CPU time, Provisioned Memory, and Invocations — plus Fast Data Transfer for bandwidth and Edge Requests per request. All five vary by region:

Vercel's own docs walk through what one function call costs: a 4 GB instance in São Paulo handling a request that uses 4 seconds of active CPU and stays alive 10 seconds total comes to $0.0002456 (CPU) + $0.0002033 (memory) = $0.0004489 per invocation. That looks trivial in isolation — it's the volume that turns it into a bill, and the resource growing fastest under real traffic is almost always Fast Data Transfer, because every response byte counts against it regardless of whether the request triggered a function at all.

What a Typical Month Costs, and What a Bad Week Costs​

Here's the same Next.js app — Pro plan, $20/month base, 1 TB of Fast Data Transfer included — at increasing traffic, computed at both ends of the regional rate spread:

Two things fall out of this table that the "$550/TB" framing you'll see in some cost-comparison posts glosses over. First, the marginal rate never exceeds $0.35/GB ($350/TB) on Fast Data Transfer alone — the eye-watering effective-per-TB numbers people report come from adding Edge Requests, Active CPU, and Provisioned Memory on top of a workload with a lot of small responses (API routes, SSR payloads), not from bandwidth pricing being secretly higher than published.

Second, and more useful for budgeting: the effective cost per terabyte is worst for small teams, not big ones. At 2 TB, the flat $20 base fee is being amortized over just 1 TB of real overage, which is why low-traffic apps see the most shocking /TB. The \23,000 documented case reached that number because "the attack ran longer, hit pricier axes like function invocations and execution time, and nothing in the system stopped it" — it's the 30 TB row in this table with functions cost layered on, in the most expensive region, sustained for days instead of one weekend.

The Fixed-Cost Alternative​

Run the same app on a self-owned Hetzner CX33 — 4 vCPU, 8 GB RAM, 20 TB of traffic included — and the monthly bill is a flat €6.49 (about $7), full stop, at every row in the table above. Twenty terabytes is more headroom than the DDoS scenario in the table by a factor of two; the attacker saturates your bandwidth allocation for the month, not your wallet. You still want rate limiting or a CDN in front for availability during an actual attack, but that's an uptime problem, not a billing one — there's no invoice to open on Monday.

That's structurally different from what Spend Management offers on Vercel: a Hetzner box has a hard ceiling because the capacity is physically fixed, not because a billing feature is watching a meter and deciding when to pull the plug. Bex.co runs on exactly this model — push a git repo, get an HTTPS service on a box like that CX33 instead of a per-byte meter, with the deploy-from-git workflow of Render or Vercel and none of the invoice surprises.

The Real Lesson Isn't "Avoid Vercel"​

Usage-based pricing and a hard spending ceiling are close to contradictory ideas — a true ceiling means refusing traffic once it's paid for, and a platform selling elastic scale doesn't want to be the thing rejecting your viral moment. Vercel's Spend Management is a reasonable circuit breaker within that model, and the 2024 addition of hard pausing was a real improvement over notification-only alerts. But it inherits the model's core trade-off: the cap can only fire after usage has already accrued, and the only lever it has to stop further accrual is turning your app off entirely.

Teams that actually need a ceiling — a fixed number they cannot exceed regardless of what traffic does — are asking for a property that consumption billing structurally can't provide without an outage as the enforcement mechanism. The alternative isn't a different usage-based platform with a lower headline rate; it's capacity you own or lease at a fixed price, where the "cap" isn't a feature you have to remember to enable.

Sources:

• Spend Management — Vercel Docs
• Improved hard caps for Spend Management — Vercel Changelog
• Spend Management now pauses production deployments by default — Vercel Changelog
• Fluid compute pricing — Vercel Docs
• Regional Pricing — Vercel Docs
• Pricing on Vercel — Vercel Docs
• The $23,000 Vercel Bill: How Usage-Based Platforms Create Bill Shock — UsageBox
• Vercel Bill Shock: Avoid $1,100 Bandwidth Bills — DeployBase
• Hetzner Cloud Cost-Optimized Plans pricing — Bitdoze
• Hetzner Cloud — Cost-Optimized plans