Live data from Hacker News

Accident Forgiveness

fly.io

221–230 of 310 posts

Re: Accident Forgiveness

#221

There 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.

Because data storage costs money, hard billing caps require deleting both your data and its backups to stay under the hard cap. There are very few use cases where that's actually acceptable, not even development environments where people will get upset for losing their work that they haven't pushed to somewhere else yet.

Re: Accident Forgiveness

#222
post #156

Earlier quoted context omitted.

While obvious, doesn’t this make it the same as before?

The sentence he's referring to says that we might tell you after you've, uh, aggressively asked us to forgive a series of bills, that future accidents are no longer on the house. So no, it's not the same as before.

I say that because I’ve had extensive GPU bills credited or forgiven before.

Presumably there was already a point where you were going to say “you keep messing up with the auto shut-off, at some point we’re going to stop refunding you”

I’ll say it’s nice to have it explicit.

Re: Accident Forgiveness

#223

If I were fly I’d implement spending caps just to filter out unserious operators. My implementation of that feature would be when you turned it on fly would just kick you off. No serious operator wants a provider to turn their system off. So if you want that it’s pretty clear you are hosting a silly system. Which likely costs more to support and drives less margin.

And yet every single cloud let's you scale from zero and play and experiment. They know today's tinkerers are tomorrow's CTO decision makers.

Re: Accident Forgiveness

#224

>If you do something luridly stupid and rack up costs, AWS and GCP will probably cut you a break. [...] Everyone does. If the incidents that made the rounds here in the last few months are any indication, they'll start out insisting you pay no matter what. You'll then have to write a blog post about it, post it to Twitter, HN, and Reddit, get a couple hundred comments expressing anger at the provider, and wait for so…

What are you referring to, exactly? That doesn’t sound like AWS at all.

AWS are very well-known for bill forgiveness. It’s not something set in stone, but if your bill explodes accidentally, even due to a mistake you made, they will normally forgive it if you ask them. You don’t need to go running to social media at all.

Re: Accident Forgiveness

#225
post #43

There 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.

I promise, you are not the first person to have thought of this, and, believe it or not, there are reasons other than malice and avarice that cloud providers don't terminate service based on billing caps. Terminating service is a big deal. We agree completely about surprise billing.

Let's not sugar coat it.

The problem is 100% technical. Detecting unexpected charges, scaling and restriction in real time is hard.

It's easier to just charge people money than come up with good ways to avoid charging them, and deal with edge cases as a manual process.

Sure. I get it. What company has an internal team that's like "ooo... lets find ways to cap the amount of money people pay us".

No one.

That's why.

> there are reasons other than malice and avarice

Right.

It's just avarice. There's no other reason.

Re: Accident Forgiveness

#226
post #43

Earlier quoted context omitted.

I promise, you are not the first person to have thought of this, and, believe it or not, there are reasons other than malice and avarice that cloud providers don't terminate service based on billing caps. Terminating service is a big deal. We agree completely about surprise billing.

Let's not sugar coat it. The problem is 100% technical. Detecting unexpected charges, scaling and restriction in real time is hard. It's easier to just charge people money than come up with good ways to avoid charging them , and deal with edge cases as a manual process. Sure. I get it. What company has an internal team that's like "ooo... lets find ways to cap the amount of money people pay us". No one. That's why. >…

> The problem is 100% technical. Detecting unexpected charges, scaling and restriction in real time is hard.

> It's just avarice. There's no other reason.

Re: Accident Forgiveness

#227
That's why my phone SIM is still not a subscription but rather I manually buy credit each month. The price is even lower than subscription and benefits exceed it, shitloads of Gb and minutes. If I'll use roaming I'll pay for a more expensive credit that month but I have piece of mind I won't be charged thousands of euro at the end of the month.

Like telecom providers of course cloud providers could have metered service billed under "get only as much as you paid" policy but it's obviously they totally and in bad faith don't want that.

Re: Accident Forgiveness

#228

>If you do something luridly stupid and rack up costs, AWS and GCP will probably cut you a break. [...] Everyone does. If the incidents that made the rounds here in the last few months are any indication, they'll start out insisting you pay no matter what. You'll then have to write a blog post about it, post it to Twitter, HN, and Reddit, get a couple hundred comments expressing anger at the provider, and wait for so…

What are you referring to, exactly? That doesn’t sound like AWS at all. AWS are very well-known for bill forgiveness. It’s not something set in stone, but if your bill explodes accidentally, even due to a mistake you made, they will normally forgive it if you ask them. You don’t need to go running to social media at all.

You're right, I was getting two relatively recent posts mixed up:

1. After a DDoS attack, someone got a $100k bill from Netlify for his static site and after he asked to have it waived, they generously reduced it to $5k. Only after his posts about it blew up did Netlify waive it completely. [1]

2. Someone got a $1k bill from AWS because lots of people made _unauthorized_ requests against his empty S3 bucket. AWS did agree to waive it immediately, prior to any social media posts. [2]

I probably just remembered (2) as "that ridiculous billing situation involving AWS" but got the details of what exactly happened mixed up with (1).

[1] https://news.ycombinator.com/item?id=39520776

[2] https://news.ycombinator.com/item?id=40203126

Re: Accident Forgiveness

#229
post #8

It'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.

You still can. My company rents space from Cogent communications, and they are very good at customer service, although the offering of "rent a cage and get a pipe" is a lot more DIY than AWS.

They also offer VPSes.

Re: Accident Forgiveness

#230
This is why I love Hetzner. It has billing alerts. What was so difficult about it that fly had to rebuild their system?

Also, do everything except databases inside kubernetes. Deploy kubernetes across multiple clouds via wireguard. Label your instances properly on each provider. Prefer bare metal instances where available. Migrate your workloads accordingly. Force cloud providers to earn your money. Don’t however have both workloads running at the same time in multiple providers as you will eat insane data costs.

Post reply on HN