The economics of a free static site
There's a story that made the rounds a while back: someone hosted a simple static site on Netlify, got DDoS'd, and received a bill for $104,000. The site was a dictionary — a small project, no revenue, just a useful thing someone built. The bill came from bandwidth: $55 per 100 GB of egress, plus — notably — a charge for ingress traffic, which most providers bill at zero. After the public outcry, Netlify "generously" reduced the bill to 5%, which still left the owner owing $5,000 for a site that had cost nothing to run before the attack.
I run a static site too. It's free, it's been free, and I'd like to understand why — and what could change that. The Netlify story is a useful lens for thinking about the economics of the whole category.
The trap: free tier, no ceiling
The core problem with Netlify's model (and others like it) is that the free tier has no ceiling. If traffic exceeds the quota, the site keeps serving — and keeps accruing charges — rather than stopping. The owner's only protection is a billing alert that arrives after the damage is done.
Compare that with the model that Firebase and Cloudflare use: when you hit the free limit, the site stops. You lose availability, but you never lose money. For a hobby site, losing availability is an acceptable outcome; losing $104,000 is not. The industry term for this is a "maximum out-of-pocket" option, and it should be the default for any service that advertises a free tier.
"If you're hosting a small site that gets DDoS'd, don't." — Netlify's reported response
That quote, from the thread, is a perfect summary of the attitude: the risk is the customer's, the revenue is the platform's.
Why my site is different
My site is hosted on sr.ht Pages, which is free and — importantly for this discussion — has no metered bandwidth billing at all. It's static files served from a CDN; there's nothing to meter beyond plain hosting, and the hosting is provided free as part of a development platform's ecosystem. That's a very different economic model from "free tier of a metered service."
But I don't rely on the kindness of a provider. The site is also designed to be portable: plain HTML, no build step, no server-side code, no proprietary features. The entire history ships as a git bundle that anyone can clone. If sr.ht Pages ever changed its model, introduced metered billing, or disappeared entirely, the site could move to any static host (or no host — it's just files) in under an hour.
That portability is the real answer to the $104k problem. The people who got burned were locked in — their sites were built for Netlify's platform, with its build pipeline, its functions, its edge network. They couldn't leave easily, so the bill had leverage. My site has no leverage point: it's a directory of HTML files. The only thing keeping it on any particular host is convenience.
The economics of independence
There's a deeper point hiding in this story. A static site is almost free to serve — the marginal cost of one more request is fractions of a cent, and for a personal site the total traffic is tiny. The $104k bill wasn't a reflection of real cost; it was the price of a platform's pricing model meeting an attack. The discount to 5% was an admission of exactly that: the "real" price was always a fraction of the listed price, but the listed price exists to capture whoever doesn't fight back.
For an independent site, the lesson is: understand what you're actually paying for, and keep the exit door open. My site costs nothing, and would cost almost nothing to move anywhere. The value is in the content — which lives on my disk, in my git history, in a bundle anyone can verify. The host is a convenience, not a dependency. That's the economic position I want to be in, and it's the one the $104k story is a warning against abandoning.
Filed after reading the Hacker News thread on the Netlify billing incident. My hosting choice (sr.ht Pages) and my portability infrastructure (git bundles) are discussed in the colophon.