Why your Vercel bill spikes — and how flat pricing fixes it

The scary part of hosting is not the monthly fee. It is the month the fee changes on its own. You ship a site, traffic does something you did not expect, and the bill at the end of the month is a number you never agreed to. On metered hosting, your bill is a function of traffic — and traffic is the one input you do not fully control.

Metered billing makes traffic your problem

Metered hosting charges by usage: requests served, function invocations, gigabytes of bandwidth, compute-seconds. When traffic is steady, the meter is predictable and the bill is fair. The trouble is that traffic is not always steady, and a lot of what hits a public URL is not a paying visitor. A post goes viral. A scraper crawls every page. A bot hammers an endpoint. Each request turns the meter, and the meter does not care whether the request came from a real reader or a script.

That is the structural issue. With a usage meter, a spike you did not cause and did not want still lands on your invoice.

The documented cases

These are not hypotheticals. A few well-reported examples:

• Cara (Vercel), June 2024. A social app went viral and ran up roughly $96,000 in serverless function overage in a single month, peaking around 56 million function invocations a day. (Hacker News thread).
• A personal site (Netlify), 2024. A developer was billed $104,500 for a simple static personal site after a bandwidth spike of about 60TB over four days — on a long-standing free account. The charge was reduced, then waived after the story spread. (Hacker News thread). Worth saying clearly: Netlify has since changed its free tier to hard-cap — sites pause instead of running up overage — so this is a past incident, not how their free tier behaves today.
• Jmail (Vercel), early 2026. A project drew around 450 million views and generated a bill near $50,000. Vercel’s CEO offered to cover it.

Two of those three ended with the charge forgiven. That is good of the companies involved — and it is also the point. When the safety net is a discretionary courtesy that depends on your story going viral, it is not a cap. It is a hope.

Why it happens — it is the billing model, not a bug

None of this means these hosts are broken or careless. They are fast, well-built, and they mitigate abuse. The spikes come from the billing model itself: usage is metered, and by default there is no automatic hard ceiling on spend. On Vercel Pro, spend management is something you opt into; it is not on by default. So unless you have already set a limit, the meter keeps running while traffic does whatever it does.

This is the same property that makes metered cloud billing flexible for big, sophisticated teams — you pay for exactly what you use, and you scale without asking permission. The flip side is that “exactly what you use” includes the traffic you did not want.

The attack-traffic angle

The sharpest version of this is a denial-of-service event. Here it matters to be precise, because it is easy to overstate. Metered hosts do mitigate attacks — the critique is not that they leave you undefended. The critique is what the meter counts while mitigation kicks in. Vercel’s own DDoS-mitigation docs put it plainly:

“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.” (Vercel DDoS mitigation docs)

Read that twice. Requests served before mitigation engages are billed. And anything not classified as an attack — including ordinary bot and crawler traffic — is billed as normal usage. Combine that with no automatic hard spend cap by default, and a bad day can become a bad invoice.

How flat pricing removes the variable

Flat pricing changes the shape of the problem. The price is a fixed number per month, and there is no usage meter underneath it. Traffic going up does not move the bill, because the bill is not connected to traffic in the first place. A viral day, a scraper, an attack — none of them change what you owe.

It helps to know where the traffic actually lands. shiply.now serves every site from Cloudflare’s edge, and Cloudflare provides unmetered, automatic DDoS mitigation on all plans — it absorbs attack traffic rather than billing it. In Cloudflare’s own words, “we will never jack up your bill after the attack” (Cloudflare, unmetered mitigation). So the CDN and attack traffic is absorbed at the edge, never metered back to the site owner.

shiply.now pricing is flat: $0, $8, or $24 a month, in USD, with no usage meter. The plan price is a hard ceiling. You can read the exact tiers on the pricing page, but the short version is that the number you see is the number you pay, regardless of what your traffic does.

When metered pricing is the right call

To be fair: metered pricing is not a trap, and it is genuinely the better fit for some teams. If your workload is heavy server-side compute, long-running functions, large data egress, or anything where you actively want to scale spend with demand and have the monitoring to watch it, a usage meter gives you precision a flat plan cannot. Pay-for-what-you-use is the honest model when usage is the thing you are buying.

The mismatch is when a static site — a personal page, a brochure site, a client project, something an agent published in one call — sits on top of a billing model built for elastic compute. For that kind of site, the meter mostly buys you exposure to a spike you will never benefit from. A flat ceiling fits the work better.

The short version

On metered hosting, your bill tracks traffic, and traffic includes bots, crawlers, and the requests served before an attack is mitigated — with no automatic hard cap by default. The documented cases are real, and the forgiveness was discretionary. Flat pricing removes the variable entirely: a fixed price, no meter, served from an edge that absorbs attack traffic instead of charging you for it. If you are hosting a static site, that is usually the trade you want.