[tptacek]

We talk about warnings in the post. We'll do that at some point. The hard part about caps is what to do when someone hits them.

If there was a way to make caps work for our core customers, we'd do it. We're open to ideas. A theme of our work this past month and these next several months is extracting maximal value from ANFWWAONW, our new billing system. The thing you have to remember though is that our belief about our core customer is that they are averse to nothing more fiercely than service disruption.

We're not in principle opposed to caps. We just don't have a product story for them that we're comfortable with. Keeping you from spending more money than you wanted to is an explicit product goal of ours (again: see post); we're just very wary of trading availability off against that goal.

[Alacart]

Configurable warnings as webhooks would be pretty cool. Then I can automate whatever needs to happen on my side.

I already automate apps, machines, etc with the machines API and GraphQL, so my big worries in this area are:

- Woops, some bad logic deployed too many machines (sounds like this policy helps) - Some kind of mistake or attack that just explodes bandwidth usage suddenly

[Aeolun]

You are comfortable scaling a service down to zero when configured to do so though.

Of course that comes up again when anyone sends a request, but that feels sort of in the same category.

That said, I do understand that building your service for people like me that’d rather be restricted to just $50/month doesn’t really make sense.

[tptacek]

I don't think anyone with a serious app running on us will use a cap. Just stay fixated on this scenario: a deploy-only token gets stolen, and the attacker (like most cloud attackers) uses it to stand up a bunch of Monero miners. As a consequence... their main app goes down? Who would be OK with that?

[Aeolun]

I think the cap (if they had any) would probably reflect the amount they stand to lose if their app goes down. If your app brings in $1000/h, you don’t necessarily care about spending that amount on servers. When your costs rise to $10k/hour, you might want to go with the nuclear option.

Of course it’s nicer if you can be certain that your provider is going to refund you the excess, but I feel like it’s hard to count on it. Or at least, harder than having explicit rules, which you just can’t really do for those sitations that are sensitive to fraud.

Honestly, if I did set a cap I’d be very much aware of the fact my app could suddenly die in a situation where my deploy token were stolen (but it wouldn’t matter for me, since it’s a hobby project, I care about controlling costs, not uptime).

[gwbas1c]

> Just stay fixated on this scenario: ... the attacker ... uses it to stand up a bunch of Monero miners.

This sounds more and more like an insurance policy; as opposed to a "sudden spike of load because of popularity" situation.

IE, all our talk about usage caps is really missing the point about what needs to be protected against.