Thomas, every time I read something you write it's a delight. I love your writing style, and it reads to me like you're always putting effort into making it succinct yet unambiguous, without unnecessary embellishment.
Accident Forgiveness
31–40 of 310 posts
Re: Accident Forgiveness
#32the biggest reason of I am not using aws, google cloud, vercel etc... for my personal projects is surprise bills. I am not earning anything from them so I can only put $50 but can't afford $500 or $5000. so still i will feel much more secure if I can put hard limit and absolutely sure my bill will never go above $50. (or cloud billing insurance :)) but you got my attention, i can try fly.io
Except for things like student accounts, which we're working on, I don't think hard limits are coming any time soon. Our expectation is that the enforcement of hard billing limits would mostly make customers furious with us. If you read to the end of the post, the direction we're going is preemptive detection of weird billing spikes, so you don't even have to notice and ask us.
If you're really only looking to spend $50, we should put our cards on table and say that we're generally not making product pricing decisions with you in mind. If your needs are pretty straightforward, there are hosting providers that will do a better job of serving that business than we will.
Re: Accident Forgiveness
#33I really, really wish there was just a way to put a hard limit on how much a cloud could charge me. I am never going to want to spend 200k of my personal money on some project on a cloud. Never. I don't even want my ant-based basket viewing project simulator to cost me 1 thousand dollars because it went viral and all clouds overcharge for bandwith. Just let me put in a limit.
I think this sounds easy, but it’s actually quite nontrivial in practice. You need special handling of such a limit for each kind of resource. E.g. when my limit is reached to they remove the database, along with all backups, and all objects on S3? Since storage is billed, it should also be stopped when the limit is reached, right? I think in practice among companies paying most of their revenue, there’d be zero inte…
It there was a law about this companies would find a way. Where there's any uncertainty they can simply eat those edge costs, the extremely fat profit margins cover it easily.
Re: Accident Forgiveness
#34Thomas, every time I read something you write it's a delight. I love your writing style, and it reads to me like you're always putting effort into making it succinct yet unambiguous, without unnecessary embellishment.
The trick is just that I write specifically for this place.
Re: Accident Forgiveness
#35Earlier quoted context omitted.
I think this sounds easy, but it’s actually quite nontrivial in practice. You need special handling of such a limit for each kind of resource. E.g. when my limit is reached to they remove the database, along with all backups, and all objects on S3? Since storage is billed, it should also be stopped when the limit is reached, right? I think in practice among companies paying most of their revenue, there’d be zero inte…
I don't think any of these requirements are necessary. A basic "if I reach my bill limit, turn off things that are billing" toggle would suffice for 80%+ of users, especially with better billing controls/per-team billing accounts. I think you run into more problems/user frustrations with a tenuous conditional-shut-off approach. My tinfoil hat is that a lot of cloud billing is accidental, probably from "lab environmen…
I mean, those S3 objects, those backups, those databases, are billing.
“Turning them off” means deleting them.
Re: Accident Forgiveness
#36It's unfortunate that the solution to cloud pricing complexity that all providers are adopting is – add even more complexity on top. The number you see on your bill is increasingly calculated by running some black box algorithm on top of the billing events your resources generate. Was it accidental or not? What is a "weird" deployment vs a normal deployment? By what factor should the spikes on your billing graph be s…
Anyone else remember we had widely available and completely understandable options to rent everything from baseline web-hosting all the way up to private rack services for actual years before AWS came along and apparently all of that was forgotten, Warhammer 40K style?
I've rented a VPS from a vendor for going on 20 years now (Holy fuck I'm old) and I've never once been surprised at the bill.
Re: Accident Forgiveness
#37Earlier quoted context omitted.
I don't think any of these requirements are necessary. A basic "if I reach my bill limit, turn off things that are billing" toggle would suffice for 80%+ of users, especially with better billing controls/per-team billing accounts. I think you run into more problems/user frustrations with a tenuous conditional-shut-off approach. My tinfoil hat is that a lot of cloud billing is accidental, probably from "lab environmen…
I mean, those S3 objects, those backups, those databases, are billing. “Turning them off” means deleting them.
Sounds good to me, that's what offsite backups are for (if the data is even necessary)
Re: Accident Forgiveness
#38There is a very obvious fix for surprise billing. Enforce a billing cap and terminate service if it's met. Even better if you send alerts when the cap is approaching.
If I pay $39/month, a default cap should be $39 per-month. Otherwise, let me set a cap I am comfortable with.
Surprise billing is never good for customers, only the business.
Re: Accident Forgiveness
#39[deleted]
Re: Accident Forgiveness
#40Earlier quoted context omitted.
I don't think any of these requirements are necessary. A basic "if I reach my bill limit, turn off things that are billing" toggle would suffice for 80%+ of users, especially with better billing controls/per-team billing accounts. I think you run into more problems/user frustrations with a tenuous conditional-shut-off approach. My tinfoil hat is that a lot of cloud billing is accidental, probably from "lab environmen…
I mean, those S3 objects, those backups, those databases, are billing. “Turning them off” means deleting them.
It doesn't have to be though?
The provider could reject further access to them (reads / writes) once the limit is reached. The cost of actually keeping objects as "cold" storage has a natural cap per billing cycle since those are billed based on time.