Skip to main content

Vercel Bill Shock: The Real Math Behind a $700+ Traffic Spike (and Why the Same Spike Is Free on Owned Hardware)

8 min readDora NodaDora Noda
Share
On this page

A side project hits the Hacker News front page on a Saturday. By Monday, the founder isn't celebrating the traffic — they're staring at a Vercel invoice that jumped from $20 to $700. That's not a hypothetical: it's the documented shape of a recurring 2026 postmortem, and the worst versions of it go a lot higher — a $23,000 bill after a DDoS, a $3,200 charge for attack traffic that was never a real visitor at all.

None of that requires anything exotic to go wrong. It's the ordinary arithmetic of $0.15/GB once a spike clears the included allowance — and it's worth actually doing that arithmetic, line by line, instead of just wincing at the total. Because the same spike, run through the numbers, costs nothing extra on a flat-rate box a team already owns.

The Meters That Fire During a Spike​

Vercel's Pro plan isn't billed on one "bandwidth" line — a viral spike trips four separate meters at once, and only one of them is the one people brace for:

MeterIncluded (Pro)Overage rate
Fast Data Transfer (egress to visitors)1 TB/month$0.15/GB (up to $0.35/GB in some regions)
Fast Origin Transfer (function → edge, billed from byte one)10 GB/month$0.06/GB
Function Invocations1M/month$0.60 per million
Edge Requests (every request the network handles, including static assets — and where Edge Middleware execution is metered)10M/month$2 per million

That last row is the one worth sitting with. Edge Middleware doesn't get a separate meter with its own rate card — it runs as an edge function on the request path, and its invocations count as Edge Requests. The catch is matcher config: a middleware.ts with no scoped matcher runs on every route, including images, fonts, and JS chunks, not just page loads. A site that thinks it's serving 2 million page views can quietly be running middleware — and therefore billing Edge Requests — 15–20 times that often, once every sub-resource is counted.

The Worked Spike​

Here's a concrete version of the anecdote, recomputed line by line rather than left as a vague "bandwidth got expensive."

The scenario: 2 million page views over a 72-hour weekend spike — a plausible HN-front-page-to-Monday-morning window. HTTP Archive's 2025 Web Almanac puts the median full page weight (HTML + CSS + JS + images + fonts, everything a browser fetches to render one page) at roughly 2.6–2.9 MB; call it 2.7 MB. At ~20 requests per page load (the HTML document plus its sub-resources), that's:

  • Total data transferred: 2,000,000 × 2.7 MB ≈ 5.4 TB
  • Total requests: 2,000,000 × 20 ≈ 40 million

Assume it's a mostly-static marketing page or blog post — the kind that actually goes viral — so 90% of bytes get served from CDN cache and only 10% of page loads trigger a real function execution (dynamic/personalized responses, or the cache still warming under sudden load). Recomputing each meter:

  • Fast Data Transfer: 5.4 TB − 1 TB included = 4.4 TB (4,400 GB) overage × $0.15/GB = $660
  • Fast Origin Transfer: 10% of 5.4 TB = 540 GB − 10 GB included = 530 GB × $0.06/GB = $31.80
  • Function Invocations: 10% of 2M page views = 200,000 invocations — well under the 1M included = $0
  • Edge Requests: 40M − 10M included = 30M overage × $2/million = $60

Total overage: ≈$752, plus the $20/month Pro seat = ≈$772 for the month. That lands squarely inside the real range reported for this exact failure mode — a Pro plan escalating from $20 to somewhere between $700 and $1,100 purely from a traffic spike clearing the 1TB allowance.

The breakdown also answers the actual question buried in every "bandwidth got expensive" postmortem: raw egress dominates (88% of the overage), Edge Requests is the sneaky second line item nobody models (8%), and function compute — the thing everyone assumes serverless bills you for — is nearly free (0%) in this scenario. The meter that bites is bytes and request count, not CPU time. A crawler pulling ~8.4 TB of media in one documented case generated a $1,477 invoice with roughly $1,267 of it in bandwidth alone — same shape, same dominant line item.

Netlify Isn't the Escape Hatch​

It's tempting to read "Vercel is expensive" as "switch platforms," but the same spike shape hits Netlify too, just at a different sticker price. Netlify scrapped its older flat overage rate — $0.55/GB — in April 2026 for a credit-based model: bandwidth costs 20 credits/GB, and a Pro plan auto-recharges in $10 packs of 1,500 credits (≈75 GB per pack) once included credits run out.

Run the same 5.4 TB spike through that: roughly 72 recharge packs at $10 each ≈ $720 in bandwidth alone — landing within shouting distance of the Vercel number, by a different route. The point isn't that one platform is secretly worse; it's that a per-GB (or per-credit) meter is a per-GB meter regardless of which vendor prices it, and a mid-2026 pricing pivot that cut the sticker rate by more than half is itself a sign the number isn't stable ground to plan a budget around.

Why the Bill Arrives Before the Warning​

The other structural piece of "bill shock" isn't the rate — it's that nothing stops the meter from running. Vercel has no default spend cap: usage-based billing is "as you go, uncapped" unless a team manually opens Settings → Billing → Spend Management and sets a hard ceiling, at which point Vercel can pause the deployment rather than keep billing past it. That control exists, but it's opt-in and buried a few clicks deep — most teams don't discover it until after the invoice that would have justified turning it on. Compare that to AWS or GCP, where budget alerts and hard caps are a first-class, front-and-center part of onboarding for exactly this reason.

That asymmetry compounds the meter problem from the last section: not only does a spike trip four billing dimensions at once, nothing is watching any of them in real time by default. A DDoS or a scraping bot doesn't know or care that it's driving up someone's invoice — from the platform's side, hostile traffic and a viral success story generate an identical line item. The $23,000 DDoS bill and the $700 HN-front-page bill are the same failure mode wearing different causes.

Same Spike, Owned Hardware​

Now run the identical 5.4 TB event against a flat-rate box instead of a metered platform. Hetzner's dedicated-server line ties bandwidth allowance to port speed: a 1 Gbit uplink carries contractually unlimited traffic — the 20 TB/month allowance (then €1/TB overage) only applies to the 10 Gbit tier. An AX52-class box (8-core Zen 4, 64 GB DDR5 ECC, dual NVMe) runs in the neighborhood of €70–75/month (~$76–82) after Hetzner's June 2026 dedicated-server price adjustment — with a 1 Gbit port included.

Does that port physically survive the spike? 5.4 TB spread over 72 hours averages out to:

5,400,000 MB72×3,600 s≈20.8 MB/s≈167 Mbps sustained\frac{5{,}400{,}000\ \text{MB}}{72 \times 3{,}600\ \text{s}} \approx 20.8\ \text{MB/s} \approx 167\ \text{Mbps sustained}

Even a generous 5x burst factor for the actual peak traffic hour lands around 835 Mbps — tight against a 1 Gbit line, but inside it, and real-world traffic is never perfectly flat, so the effective margin is wider than that worst-case number suggests. The marginal cost of absorbing the entire spike: $0. The box was already being paid for at a flat monthly rate before a single extra visitor showed up, and it's still being paid for at that same rate the month after.

That's the whole mechanism, reduced to one sentence: metered platforms convert unplanned success into an unplanned bill, and flat-rate hardware doesn't, because there's no meter reading to spike in the first place.

What Actually Changes​

None of this makes Vercel a bad product — the convenience it sells (zero-config previews, instant rollbacks, a git-push-to-live workflow) is real, and for workloads with predictable, bounded traffic, metered pricing is a fine trade for that convenience. The economics invert specifically when a workload's traffic is not predictable — a viral spike, a scraper pulling terabytes of media, a DDoS that racks up a five-figure bill on legitimate-looking-enough requests. That's precisely the risk profile a per-GB meter prices the worst, because the vendor's revenue goes up exactly when the operator's business risk does too.

If you want the git-push deploy experience without a bandwidth meter that can turn a good weekend into a bad invoice, that's the gap self-hosted platforms are built to close. Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with no per-GB surprise waiting in next month's bill. Star the repo on GitHub or deploy your first app today.


Sources​

Related articles

Run this on infrastructure you own

bex is the open-source, AI-native Render alternative — push a git repo and get a running HTTPS service on your own machines.

Get started with bex