Cloud billing has no seatbelt: why a $50/mo account can hit $20K overnight
Here is a sentence no one wants to write. From a r/googlecloud thread where the original poster is staring down a $36,000 bill, a second user chimed in with his own version of the same nightmare:
Sit with the details, because each one is a separate failure of the thing most people assume protects them:
- A $50-a-month account billed nearly $20,000 in a day.
- The “billing cap” was breached — it didn’t hold.
- The card was charged in chunks — $2,000, then $1,000 — as the meter ran.
- When the card finally declined, the servers kept running.
- The account was automatically promoted to a higher spending tier, raising the ceiling instead of stopping.
None of that is a glitch. It’s how cloud billing is built. Let’s take apart why, and then the one thing that actually stops it.
A “budget” is not a cap
This is the misunderstanding at the center of nearly every bill-shock story: people set a “budget” in the cloud console and believe they’ve set a limit. They haven’t. Here is Google’s own documentation, quoted by another user in that same thread:
The budget doesn’t automatically set a hard cap on spending. We recommend that you set your budget amount below your available funds, to account for delays in usage reporting.
Read plainly: a budget is a smoke alarm, not a sprinkler. It emails you when spend crosses a line. It does not switch anything off. As one commenter put it flatly, “GCP doesn’t have billing caps.” The same is true at AWS and Azure — none of the big three give a normal paid account a true hard ceiling out of the box. The default, everywhere, is the meter keeps running.
And notice the second half of Google’s own sentence — “delays in usage reporting.” The bill you can see lags the spend that’s actually happening, often by hours. So even the alarm arrives late. By the time the email lands, the number is already bigger than the email says.
Why the “cap” rose instead of holding
The most chilling line in that account is “when billing rise, billing cap treshold rise as well.” That sounds backwards until you understand what the number really is. It was never a spending limit — it was a credit limit, more like a card’s, and the platform’s instinct when you approach it is to extend you, not stop you. Good behavior for a customer growing a real workload. Catastrophic for a victim of a runaway process, because the safety rail you thought you had is actually an accelerator.
That’s how a declined card doesn’t end the story. The resources keep serving, the account gets bumped to a higher tier, and the debt keeps climbing past the point where any card would have stopped it.
A budget is a smoke alarm, not a sprinkler.
Whose fault is it? (a fight worth skipping)
That thread, like every one of these, turned into an argument. One camp says the platform should never let this happen. Another points out the accounts often had unrestricted API keys — credentials that could reach any paid service — and calls it user error, “like leaving your front door open and blaming your insurance company.” (There’s a real security angle here: how a single exposed key becomes someone else’s $55,000 bill, and the five settings that shut it, is its own writeup.)
You can spend all day assigning blame. Skip it, because both camps agree on the one fact that matters: there is no hard cap. Even the harshest “it’s your own fault” commenter conceded that the missing cap “is a valid complaint.” The security mistakes decide whether the meter runs away. The billing design decides how far it runs once it does — and the answer is: as far as it can reach before a human happens to look.
What actually stops the meter
Since the platform won’t give you a floor, you build one. On Google Cloud the documented pattern is a kill switch: a budget alert triggers a small automated function that disables billing on the project when spend crosses a threshold. That’s the only mechanism that stops spend rather than emailing you about it. Set it up once, on every project.
Two honest caveats, so you don’t over-trust it:
- It’s not instant. Because usage reporting lags, some spend can accrue between the trigger and the shutoff. It turns a five-figure disaster into a smaller one; it doesn’t make it zero.
- You have to build it yourself. It isn’t a checkbox. On AWS and Azure the equivalents are similarly do-it-yourself. If you’d rather not, that’s exactly the kind of setup I’ll wire up for you (see below).
For the AI side of this — where a looping agent or a leaked model key can pile up spend fastest — the same principle takes the shape of a gateway that refuses calls once a limit is hit instead of just logging them. That fail-closed pattern is the kill switch applied to model spend.
The deeper problem: unlimited liability by default
Strip away the specifics and every one of these stories is the same shape. You sign up, you hand over a card, and you accept — usually without realizing it — unlimited liability. Your worst-case bill isn’t your budget, isn’t last month times two, isn’t anything you chose. It’s however much compute the platform will let a runaway process consume before you notice, which for a healthy account is effectively unbounded. That default is the real exposure, and almost nobody opts out of it because almost nobody knows they opted in.
The cloud gives you a car with a throttle and no brake, and hands you the keys assuming you’ll never need to stop hard. Most months you don’t. The one month you do, there’s nothing under your foot.
If you’re not sure whether your accounts have a real hard cap — an automated kill switch, not just a budget email — that’s a ten-minute thing to check, and the wrong answer is expensive. It’s just me for now, so I read and reply to every message myself, usually within a day. Send me your setup and I’ll tell you where you’re carrying an uncapped bill — the projects with no kill switch, the keys that can reach paid services — in a one-page writeup within a business day. And if your brakes are already fitted, I’ll tell you that too.