Dora NodaBetween May 21 and May 25, 2026, a Vercel Pro customer's project got hit with more than 2TB of outbound traffic in four days. Their invoice, normally $20 to $60 a month, came back at $231.71. Vercel support called the charge non-refundable and closed the ticket without escalating to a human. What makes that case worth reading isn't the dollar amount — it's the date. Vercel had made DDoS-mitigated traffic free three weeks earlier, on May 18, 2026. The bill happened anyway.
That's the real story in mid-2026, and it's narrower and more current than the bigger numbers that made the rounds earlier — a widely reported $23,000 bandwidth bill from an earlier DDoS incident, and a separate $1,100 charge from a month of unrecognized bot traffic. Those figures come from secondary write-ups rather than Vercel's own incident record, so treat the exact totals as reported rather than verified. What is verifiable, straight from Vercel's documentation and its own community forum, is the policy that changed and the two carve-outs it left standing — and those carve-outs are why a bill like the $231.71 case is still possible today.
What Actually Changed on May 18, 2026
Vercel's changelog entry, published May 18, 2026, describes a real shift in how attack traffic gets billed: traffic that the Vercel Firewall denies, challenges, or rate-limits — including DDoS mitigation, Attack Mode, IP blocking, and custom WAF rules — no longer counts toward CDN Requests or Fast Data Transfer. Before that date, Vercel billed for bandwidth and requests even when its own firewall correctly identified and blocked the traffic as malicious. The changelog's own framing: "No surprise bill when a scraper hammers your product pages, a credential-stuffing botnet hits your login route, or a bot abuses an expensive endpoint."
That's a genuine fix, not a marketing gesture — it applies automatically, with no configuration required, to every plan tier. It closes off exactly the failure mode the older $23,000 and $1,100 stories describe: a firewall that sees the attack, does nothing to stop the billing meter, and lets the invoice run up in lockstep with the attack's traffic volume.
The Gap the Policy Doesn't Close
Vercel's own DDoS mitigation documentation states the free-traffic policy plainly, then immediately draws two boundaries around it:
Usage will be incurred for requests that are successfully served prior to us automatically mitigating the event. Usage will also be incurred for requests that are not recognized as a DDoS event, which may include bot and crawler traffic.
Those two sentences are the whole gap. The first is a timing window: mitigation is reactive, built to fingerprint abnormal request patterns in real time, which means every request served in the seconds-to-minutes before the firewall recognizes and blocks the pattern is billed at the normal rate. The second is a classification gap: traffic that never gets flagged as an "attack" in the first place — a slow-burn scraper, a distributed botnet spreading requests thin enough to look like organic load, a crawler hammering one expensive page — is never denied, challenged, or rate-limited, so the free-traffic exemption never applies to it at all.
The May 21–25, 2026 case fits one of those two categories. The traffic sustained over four days, not minutes, and Vercel's own self-service refund tool marked every line item on the invoice as ineligible for adjustment — behavior consistent with traffic that was served and counted as ordinary usage rather than traffic the firewall recognized and blocked for free. A separate, smaller community report describes the same pattern at $170 in extra charges from a shorter DDoS event, with support again declining a refund on the grounds that usage charges are final. Two different-sized incidents, same mechanism, both after the May 18 fix took effect.
Both gaps trace back to the same design constraint: Vercel's Firewall has to decide a request is illegitimate before it can be denied, challenged, or rate-limited for free, and that decision runs on pattern recognition — request-rate anomalies, fingerprinting signals, behavioral heuristics — not a simple traffic-volume threshold. A concentrated flood that spikes far above a site's normal baseline is exactly the shape the system is built to catch fast. A slower, distributed, or merely aggressive-but-plausible pattern — a botnet spread across enough source IPs that no single one looks abusive, or a scraper working through a product catalog at a pace that resembles a very enthusiastic user — can sit below the threshold that triggers mitigation indefinitely, racking up billable requests the whole time it goes unrecognized.
What a Team Can Actually Do About the Gap
Vercel doesn't leave that gap completely unaddressed — it just leaves it as something the customer has to opt into, not something the platform does automatically. Three levers sit on top of the free automatic mitigation:
- Attack Mode, free on every plan, challenges all incoming traffic — not just the requests the Firewall's heuristics already flag — which is the direct answer to a slow-burn or distributed pattern that evades automatic recognition. It's a manual switch a team has to flip during an incident, not a standing default, because it also challenges legitimate visitors.
- Spend Management, available on Pro, can notify a team or automatically pause a project once usage crosses a set dollar threshold — turning an open-ended bill into a capped one, at the cost of the project going down once the cap is hit.
- Custom Rules and rate limiting let a team pre-define what "too many requests from one source" means for their specific app, rather than waiting on Vercel's general-purpose heuristics to catch a pattern tuned to look plausible.
None of the three is free of trade-offs — Attack Mode blocks real users during the window it's on, Spend Management stops the bill by stopping the site, and custom rate limits require a team to already know what abuse looks like for their traffic shape. But all three are things a team has to actively configure or trigger; none of them is the default state a project ships in.
Running the Numbers
Vercel's Pro plan includes 1TB of Fast Data Transfer before bandwidth overage kicks in at $0.15/GB; a separate meter, Fast Origin Transfer, bills from the first byte at $0.06/GB. Here's what that rate card does to the documented cases, applying the May 18 policy as the dividing line:
| Case | Reported traffic / bill | Timing vs. policy | Likely outcome under current policy |
|---|---|---|---|
| May 21–25, 2026 (Pro plan) | 2TB+ over 4 days → $231.71 | After May 18 | Still billed — sustained, multi-day traffic reads as served/unrecognized, not a blocked event |
| Community report, shorter event | $170 in extra charges | After May 18 | Still billed — same non-refundable classification |
| Reported $1,100 case | ~1.1TB in a month, bot/crawler traffic | Before May 18 (unspecified attack type) | Would likely still be billed today — bot/crawler traffic is explicitly excluded from the free-traffic carve-out regardless of date |
| Reported $23,000 case | 10TB+ over roughly a day or two | Before May 18 (attack type unspecified in reporting) | Ambiguous — if the firewall would have recognized and blocked it as DDoS, the bulk becomes free; if it read as unrecognized/scraper-style traffic, most of the bill would still stand |
The math behind the 2TB case is straightforward: 1TB included, roughly 1TB of overage at $0.15/GB is $150, plus the account's normal $20–60 baseline and whatever Fast Origin Transfer and function-execution usage rode along with it — landing in the same neighborhood as the $231.71 actually billed. The honest reading of the table's last two rows is that the policy fix genuinely helps the case it was built for — a firewall-recognized DDoS event — and does nothing for the case it wasn't: traffic that looks enough like real (if aggressive) usage that nothing ever flags it as an attack to begin with.
What Owning the Box Changes — and What It Doesn't
Hetzner bundles 20TB of outbound traffic into its dedicated servers with a 10Gbit uplink, and its cloud instances carry the same 20TB monthly allowance; traffic beyond that runs about €1/TB. That's a flat, deliberately unmetered-feeling allotment attached to the box itself, not a per-request meter tracking every gigabyte against a rate card that changes by traffic classification. A four-day, 2TB traffic spike against a 20TB monthly bundle doesn't generate an invoice line at all — there's no billing event for the box to trigger, recognized attack or not.
That's the part worth being precise about, because it's easy to overstate: owning the hardware removes the metering, not the mitigation. Hetzner's bundled bandwidth doesn't fingerprint request patterns, challenge suspicious traffic, or auto-scale to absorb a flood the way Vercel's Firewall does — that job still falls to whatever a self-hosted platform runs in front of the app: rate limiting at the ingress layer, fail2ban-style IP blocking, or a CDN/WAF sitting ahead of the origin. A team that skips that layer on owned hardware doesn't get billed for an attack, but it isn't protected from one either. What changes is narrower and more concrete than "solved": the traffic-classification ambiguity that produces a bill like the $231.71 case — was this recognized as an attack or not? — stops being a billing question, because there's no per-gigabyte invoice waiting on the answer either way.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with bandwidth bundled into the box instead of metered per gigabyte against a classification your firewall may or may not make in time. Star the repo on GitHub or deploy your first app today.
