The answer is probably quota management, where a limit on the number of VMs or size of database or something, caps the worst-case scenario, and where it's arguably easier to monitor an approach to that quota as it's more granular than billing.
Personally I think cloud providers could have an explicit "hobby mode" that limits certain things in such a way that the spend can't run away like this, with the trade-off that they're not really production grade in a sense, but then again those accounts are probably worth anything so I understand not building that out. That said, whenever I've seen one of these things happen, it always ends with "FooCloud said that as a one-time gesture of good will they would write off this accidental usage", so while briefly scary, maybe this is the system working fine overall?
https://learn.microsoft.com/en-us/azure/cost-management-bill...
I suspect that if they tried to sue you over an unpaid bill, they'd lose over issues of proper notice to you. You can't actually bill someone for a service they didn't want and didn't ask for; that's why the wash-your-car-in-traffic people are considered scammers.
How much does the problem change if you remove the word 'exactly' from here, though?
Like, I don't mind if I end up paying a couple of extra bucks. Or even tens of bucks! Some people might not mind hundreds or thousands, or even more depending on their scale.
But blowing out several orders of magnitude past my usual monthly spend is the problem I'd like to avoid.
This seems unlikely to me. What is the technical reason for this?
[1]: https://firebase.google.com/docs/projects/billing/avoid-surp...
It's not an automatic hard-stop so you could still screw yourself over pretty badly with runaway spending.
> We don't turn off services and usage because although you might have a bug in your app causing an increase in spend, you might just be experiencing unexpected positive growth of your app. You don't want your app to shut down unexpectedly when you need it to work the most.
Frankly, I don't see anything on that page that would actually prevent a surprise bill.
The structure should look like:
"My App LLC" has contract with "My Host LLC" for hosting services. "My Host LLC" provides those services via a cloud provider. If "My Host LLC" racks up a 2 million dollar bill with the cloud provider and goes out of business then I just move to "New Host LLC" and carry on.
It's not as if the patients of a Doctor who fails to pay his office rent would become liable.
This is the entire purpose of LLCs.
i like this one. the ultimate law to subjugate everybody once and for all!
Firstly, because cloud contracts generally prohibit renting out the cloud services as-is - you can build a product on top of it but not act as a reseller of their platform.
Secondly, and perhaps most importantly because setting up separate LLCs with the goal of avoiding lawful debts is the demonstrates fraudulent intent and will get your LLCs veil-pierced.
Doesn't have to be as-is - a simple infra on top of it will do
> setting up separate LLCs with the goal of avoiding lawful debts
If normal bills are paid as usual and only this kind of crap is not paid, Amazon would have a hard time proving in court that the whole point of the daughter LLC was to avoid paying bills.
"don't worry, all the work has warranted by New Quality Roofing Services IV, LLC"
although, there's very little about that structure that's unique to an LLC. it can be done the same with a corporation.
i'm certain this only works when the amount of debt being ripped off (ahem in dispute) is not a lot more than the cost to sic a really good law firm on you.
It’s not. A lot of weight should be put on the concept of “legitimate business”. Let’s say you decide to open up a car dealership and you use an LLC to buy cars then transfer them to another LLC and sell them. Then declare bankruptcy on the one containing the bills. You won’t be shielded, and you’ll likely go to jail for fraud.
The construction is to allow a business to go bankrupt with limited liability not to allow the expense account of a business to go bankrupt.
When a dealer has a floor plan (to finance their inventory), the cars that are being bought by the dealer are collateral and have liens on them.
The lien has to be satisfied (bank paid with interest) to transfer the title to a buyer or to your theoretical “another LLC.”
Just like my car would have to be, for me to get a clear title to sign over to you.
Not everyone uses a floor plan, an unsecured line of credit would be the one situation where what you’re proposing would “work”
Floor plans are one of the reasons there’s only a few (used) dealerships in town I could walk into, plunk down cash, and walk out with a signed title that day. Because they’re transferring the title to themselves, and then to me, using the chain of ownership boxes on the back,and then sending that to dmv.
I didn’t know a lot about this other than the owner at my previous company had attempted to branch into car sales before he passed away. TLDR, we couldn’t even sell or dispose of the cars with good intentions and they all got repossessed.
Why does Firebase insist on hanging the sword of Damocles over all of its customers? I’ve read so many stories before and experienced these fears the first time I was setting up Firebase…this has been going on for years
No affiliation, just happy to use a provider with actual caps.
I set up automatic recharge of $20. A small amount because not much traffic. A bad actor got ahold of our api that didn’t have rate limit yet and started spamming Africa.
Twilio had zero issue charging my credit card every second. Literally I was getting a hundred emails and bank notifications a minute. Brex didn’t stop anything.
Twilio responded that it was my fault. Yeah. I sure 100% probably should have put in that cloudflare rate limit first. But…
How easy would it be for twilio to prevent this on any level? I need rate limits? How about you rate limit credit card charges. Putting $20 recharge limit should mean $20/day or $20/hr not literal unmetered right to charge as much as possible in 20 increments.
Twilio support sent me all this info about protecting myself from African spammers who use the technique to make money from SMS charges. You know what’s more responsible than informing me of this? How about blocking sending sms to country codes known for this from the get-go and optin to send to them.
it was clear the perverse incentives that encourage twilio to massively benefit from being insecure and easily exploitable by spammers.
Ended up costing almost $3k after bill adjustment when our usual spend was $5/mo. not bankruptcy level so after fighting with support just took it as is and learned my lesson. But twilio made *50 years* of revenue in about 10minutes from their own negligence.
These folk can't even get a stable billing process; the coming surprises will be awesome.
I could easily imagine a 1,000x hour over hour growth as the social media grows.
If I was LinkedIn, I’d be very upset if Firebase pulled the cord when everyone was looking at the new launch.
but anyway, this is partially why I spin up an LLC for every app i make... just declare bankruptcy and kill it
In particular, do you use something like Stripe Atlas for that? And if so, is there any impact to your account with them when you declare a bankruptcy?
Doing a search/replace on the operating agreement for the new entity name, filing it away somewhere, etc. typically takes more time.
Over on Reddit someone got stuck with a 450k one.
Struggling to find the third thread again though. Maybe they deleted it
Also seeing an uptick in people suggesting insurance as the solution. Which seems insane to me but what do I know
Are you buying insurance against having a successful business? No one is going to sell that. Are you buying insurance against being hacked? That makes sense and does exist, but only solves one very specific version of this and isn't really about cloud billing, plus it's likely not accessible to the size of business (or individual use) who get bitten by this sort of thing. Are you buying insurance against incompetence using the services? You can get professional indemnity insurance, and I guess your own LLC could probably sue your own indemnity insurance in this sort of case, but you'd need to defend the decisions as reasonable at the time and not negligent.
A lot easier to simply not use these cloud services.
Eliminates risk of a denial of wallet like attack. That does leave risk of footguns & mistakes on my part, but that's a bit more manageable of a risk.
also, billing caps really don’t make any sense. a competitor could easily exploit that to take your service down. best to you know, architect your stuff correctly… speaking of architecture, creating a paas where you have a hard billing cap would pretty much obliterate performance as you would need round trips each time you do anything in order to confirm you’re not over the amount.
(I'd look this up myself but replies on Xitter seem to be Muskwalled)
https://x.com/tamarajtran/status/1867342095033258466
There's a really good reason that I don't link to my apps on this site (or most, for that matter). They are free apps, running on a shoestring budget.
But that whole account looks a little dodgy. The posts make it seem like one of those "I made $30K/mo, from my living room! You can too!" outfits.
But what's odd to me is that I don't often read about other people having the same experience. So... are all of you seriously with hosts that don't shut off access to your servers?
I'd rather that happen than suddenly get a bill I can't afford.
Hard Spending Limit
If you configure hard spending limits, then upon the sum of money being reached, the service will be stopped until manual user action is taken. This can result in service outages.
Spending limit: ______ $
I have read and agree with the terms: [X]
[Confirm]
Correct. Because it would change the dynamic with enterprise customers.
Right now CEO/CFO is forced to accept unlimited open ended billing. If there was a way to set a hard limit companies would utilize it as part of their annual budgeting, not just hobbyists. That would be bad for big cloud's profits.
Not what would be the consumer friendly choice, which would be to charge “same as before”, i. e $0.
Arguably worse than an average 2025 LLM.
Amazing service but its a scary one. Every time a social-media-worthy accident happens, they cancel the bill but I wonder how many are burned without recourse.
Maybe if your rack up something modest like 5K accidentally, its better to push it as high as you can and get it declined on your CC and increase your social media prospects :)
I've found it pretty nerve-wracking, then, to attempt to get some hobby projects online. I don't like writing blank checks for my hobbies..
Even if your card declines or you used a prepaid card...you're still legally liable for the full amount.
It's easy to accidentally make a bunch of information world-readable, and if a malicious user gets hold of the right details they can simply read all your content out, or even start writing bad content in, racking up a bill in the process.
Whether this is what happened here or not I have no idea. And I don't think this is even really a problem with Firebase, just an indicator of the sort of developer who ends up using Firebase and their background.
Especially on Firestore. For example, the access rules that you define on your properties are not filters(they are rules on what you can ask the system to do) even if they look like filters at first glance and the way it accessing data is billed is based on what has had to be processed to return the results and not on what the actual results were returned. This makes it very easy to create very expensive and compromised apps if you slip.
Also, unlike more traditional system, doesn't produce smoke so it passes all the smell tests and you learn about your mistakes once things go very bad.
Our API helps apps take control of their SMS verification costs by proactively blocking fraudulent and suspicious verification attempts before they ever trigger an SMS. On top of that, we let users set daily limits as an additional safety net, so surprises like this don’t happen.
Had a good experience with them.
Though I wish taking backups on firestore was easier.
I still have a couple of apps running on Firebase. I can't wait to get rid of those.
In 2016 Firebase seemed the holy grail for frontend devs and I deeply regret ever using it.
Probably because of this discussion.
To Firebase: either you must automatically condone such mistakes or implement the requested feature.
To anybody else: Does Supabase or other platforms offer this?