Every case here is publicly documented and linked to its primary source. Amounts are as reported.
They all have the same shape, and it is worth naming: nobody found out while it was happening. The discovery is always the invoice, the usage email, or a platform notification after the fact. That is the pattern this archive exists to illustrate.
These are self-reported figures from forum posts, blog write-ups and social threads. We link to the source in each case so you can judge it yourself. Where a detail is disputed or unclear, it says so. Several were later reduced or forgiven after support conversations, which is noted where known.
The cases#
The $23,000 DDoS bill · Vercel#
Attack traffic billed at the standard bandwidth rate. The detail that made this one circulate: every byte of attack traffic was charged normally. There is no "this was an attack" discount, because from the meter's point of view it is indistinguishable from success.
Cause: DDoS → bandwidth Lesson: a WAF in front of the platform is not optional at any meaningful scale. Source
The $104,000 static site · Vercel#
Reported by a developer who watched it happen to someone else. A static site — the category everyone assumes is safe.
Cause: traffic volume against per-request billing Lesson: "it's just a static site" is not a cost model. Source
The $602.21 monorepo · Vercel#
Of which $601.52 was build minutes. Almost the entire bill was rebuilding things that did not need rebuilding.
Cause: monorepo without ignore rules — every push rebuilt every project
Lesson: set ignoreCommand per project. It is a one-line fix.
Source
The AI crawler image bill · Vercel#
Two AI crawlers sent 66,500 requests in a single day. Each unique image transformation billed separately. The author's objection — that "$5 to resize 1,000 images is ridiculously expensive" — lands differently when the images are being resized for bots.
Cause: AI crawlers × image optimization Lesson: bound your image variants in config, and block the crawlers you do not want. Source
The 97GB bandwidth spike · Netlify#
97GB in three days on a low-traffic site, attributed to bot or attack traffic. Netlify has no spend cap and no automatic pause, so there was nothing to stop it.
Cause: bot traffic → bandwidth Lesson: on Netlify, prevention carries more weight, because the reaction options are thin. Source
The 100k+ DDoS charge · Netlify#
A user seeking clarification on DDoS fees and protections after a six-figure charge. The thread is one of several on Netlify's own forum on this theme.
Cause: DDoS → bandwidth Lesson: ask what your platform's DDoS position is before you need to know. Source
The request that has been open since 2020#
Worth including because it is not an incident — it is the absence of one being possible to prevent.
Netlify's forum thread "Simple question: Can you just take my site offline if I go over the bandwidth limit" has been open since 2020. So has "Limit bandwidth to avoid high billing caused by DDoS?"
Both ask for the same thing: a hard stop. Six years later, neither Netlify nor Vercel offers a true one, for reasons that are defensible but do not help the person asking.
What the pattern says#
- Traffic you did not know about is the leading cause — bots, crawlers, scrapers, attacks. Not your users.
- Per-request billing amplifies it. Image optimization and edge requests turn volume directly into money.
- Build loops are second, and cheaper to fix than to detect.
- Discovery is always late. In every case here, the owner found out afterwards.
- Refunds happen, and cannot be planned for. Several of these were reduced or forgiven. That is goodwill, not a control.
What actually reduces the risk#
In order of how much they help:
- A WAF or CDN in front of the platform. Prevention beats detection.
- Caching. Directly reduces bandwidth, Fast Origin Transfer and function duration together.
- Bounded image variants in config.
- The platform's own spend controls, if it has any — Vercel's, with the pause switch on. Netlify has none.
- Monitoring that reaches you. Which is where MONII sits, and it is deliberately fifth. If you only do one thing on this list, do the first.
Know of a documented case that should be here? Send it to support@getmonii.com with a link to the primary source. Self-reported figures only, always linked.
Questions people actually ask
How common are surprise hosting bills?
Common enough to be a recognised pattern rather than a freak event. The cases collected here are only the publicly documented ones — the ones resolved quietly through support never surface.
Do platforms refund these?
Frequently, at their discretion, particularly for clear-cut attack traffic. Several high-profile cases ended in full or partial forgiveness. It is a goodwill outcome, not a control you have.
What causes most of them?
Traffic the owner did not know about — bots, AI crawlers, scrapers or attacks — hitting a route that bills per request. Image optimization and bandwidth dominate. Build loops are second.
Find out during, not after
Every case here has the same shape: nobody knew until later. MONII pushes you when usage crosses a threshold you set.
Get MONII for iOS ›