The $23,000 Vercel Bill: How Usage-Based Platforms Create Bill Shock (and How Not To)

Every few weeks a new screenshot goes viral: a four- or five-figure cloud bill on an account that was supposed to cost twenty dollars. The platform is usually different, but the mechanics never change. Usage-based pricing is the correct model for infrastructure, and it is also a loaded gun when you ship it without the safety. The Vercel cases are the clearest current examples, but the lesson is about every usage-priced product, including, if you sell one, yours.

The anatomy of a bill-shock event

Bill shock is not one failure. It is the same four conditions lining up, every time.

• A volume event nobody modeled. A DDoS attack, a viral post, a misconfigured retry loop, a crawler swarm, or a bot army. In the $23,000 case it was a DDoS, and crucially, all of the attack traffic was billed at the normal bandwidth rate. The platform did not distinguish hostile traffic from real customers. We mapped this exact dynamic in billing for bot and crawler traffic: the meter counts bytes, not intent.
• Multi-axis pricing the customer flattened to one number. A Vercel Pro plan starts at $20 per seat, then bills on at least seven separate axes that most pricing articles compress into the single word "bandwidth." You think you understand the price; you understand one of seven dimensions. The classic trap is function duration: you pay for every millisecond a function is active, and idle time waiting on I/O or streaming a response counts as billable.
• An overage cliff with no ceiling. Past the 1 TB Pro allowance, bandwidth is $0.15/GB. That number looks harmless until a spike multiplies it. $0.15/GB times a few terabytes of attack traffic is how $20 becomes $23,000.
• No hard spend cap, and an invisible meter. Unlike AWS or GCP, where budgets at least exist (even if they alert rather than stop), many platforms ship with no spend limit at all, and most developers never learn that until the first shock bill. The damage accrues silently because the customer cannot see the meter move in real time.

Line those four up and the bill is not a bug. It is the system working as designed, against a customer who could not see it happening. That is the part that turns a big number into a viral grievance and a churned account.

Worked example: how $20 becomes $23,000

Walk the math, because the leap from a hobby plan to a five-figure invoice feels impossible until you see it. Start with a $20 Pro seat and a site comfortably inside the 1 TB monthly bandwidth allowance. A DDoS attack opens, pointing a botnet at your origin and requesting your heaviest assets in a loop. Say the attack sustains a few hundred megabits per second for a day or two before anyone notices. At a few hundred Mbps, you push roughly 2 to 5 terabytes per day; over a long weekend that is comfortably 10-plus terabytes of traffic the platform meters as ordinary bandwidth. At $0.15/GB, ten terabytes is $1,500; the documented worst cases reached $23,000 because the attack ran longer, hit pricier axes like function invocations and execution time, and nothing in the system stopped it. No single number is outrageous. The product of an unmodeled volume event and a per-gigabyte rate with no ceiling is.

The reason this recurs on the same platforms is structural, not careless. Usage-based infrastructure pricing has to bill what it serves, and serving attack traffic costs the platform real money, so passing it through is internally defensible. The gap is on the customer's side of the meter: they anchored on $20, never enumerated the other axes, and had no cap because none was offered or it was buried. The platform optimized for accurate billing; the customer needed a windshield. Both can be true, and the result is still a churned account and a viral thread.

If you are the customer: four ways not to get $23,000'd

1. Find out whether a hard spend cap exists, today. Not an alert, a cap that stops spend. If the platform does not offer one (many do not), you need a compensating control: a CDN or WAF in front that you can rate-limit, or a budget alert wired to a human who can pull the plug. The spend cap and kill switch playbook applies to platform bills exactly as it does to AI agents.
2. Enumerate every billing axis. Write down all seven (or however many) dimensions your platform meters, and which one a traffic spike actually amplifies. For edge platforms it is usually bandwidth and function duration, not the seat price you anchored on.
3. Put hostile traffic in front of the meter. A DDoS that hits your origin bills you; a DDoS absorbed by a CDN or challenge layer does not. The single highest-leverage protection against the catastrophic cases is making sure attack traffic never reaches the billed surface.
4. Watch usage daily, not at invoice time. Every bill-shock story has the same ending: "I found out when the invoice arrived." A daily glance at the usage dashboard turns a $23,000 surprise into a $200 conversation on day one. If the platform offers anomaly emails, enable them and route them to a human who can act, not to a shared inbox nobody reads; the entire value of an alert is that it arrives while the spend is still small enough to stop.

If you sell usage-based pricing: the trust is in the meter, not the model

Here is the part most platform teams miss. Usage-based pricing is not what makes customers angry. Opaque usage-based pricing is. The model is fair; the experience of discovering a five-figure charge you could not see coming is what destroys trust and produces the viral thread. If you operate a usage-priced product, the bill-shock stories are a competitive gift and a warning at the same time, and four design choices decide which one you get:

• Expose the meter in real time. The customer should see usage and projected spend today, not on the invoice. A live usage dashboard is the single biggest trust lever in usage-based billing, because it converts a surprise into a decision.
• Offer a real spend cap. Let customers set a ceiling that actually stops or throttles, not just emails them. Yes, it means some workloads pause; that is vastly preferable to a customer who churns over a bill they did not authorize. The market has already decided that a spend cap beats unlimited-until-it-isn't.
• Alert on anomalies, not just thresholds. A 50x day-over-day jump should page the customer immediately, framed as "this looks abnormal," because the abnormal cases (attacks, loops, viral spikes) are exactly the ones that produce shock bills.
• Make every charge legible. When the bill does arrive, each axis should be itemized and attributable, so a customer can understand and, if warranted, dispute it. This is the same handling-unexpected-bills discipline that separates a refund-and-retain outcome from a chargeback-and-churn one. Transparent metering is the entire argument for showing customers their usage.

The platforms taking bill-shock screenshots are handing you a positioning. Every "I got a $23,000 bill" thread is a customer telling the market they wanted visibility and a cap and did not get one. Build the meter and the ceiling into your product and you are selling the exact thing the angry customer wishes they had bought.

The honest take

Usage-based pricing is the right model for infrastructure, and none of these bills were the result of a broken meter. They were the result of a correct meter with no windshield: a customer billed accurately for usage they could not see, could not cap, and did not cause. The fix is not to abandon usage pricing; it is to ship it with the safety on. If you buy infrastructure, assume there is no spend cap until you prove there is, keep hostile traffic off the billed surface, and watch the meter daily. If you sell it, remember that the model is fine and the surprise is the problem: expose usage in real time, offer a cap that bites, alert on anomalies, and itemize every axis. The platforms that do this will never trend on Reddit for the wrong reason, and that absence is worth more than any pricing-page cleverness.