We're nuts for studying failure at the company and Heroku's margins was one of the things we considered to be one of the many nails in that coffin. (RIP)
(my rant here: https://blog.railway.com/p/heroku-walked-railway-run)
I had to hunt around for a host in a suitable geography with a spending limit, almost had to go on-prem (which will happen eventually, but not in the startup phase)
Waking up to bankruptcy because of bots out of your control visiting your website seems a little nuts. Adding some other bullshit on top (like cloudflare) seems even more nuts.
Yeah I can manage all that and have the machine stop responding when it hits a spending limit -- but why would I pay for the cloud if I have to build out that infrastructure?
grumble.
1. Because people vote with their wallets and not their mouths, and most companies would rather have a cost accident (quickly refunded by AWS) rather than everything going down on a saturday and not getting back up until finance can figure out their stuff.
2. Because realtime cost control is hard. It's just easier to fire off events, store them somewhere, and then aggregate at end-of-day (if that).
I strongly suspect that the way major clouds do billing is just not ready for answering the question of "how much did X spend over the last hour", and the people worried about this aren't the ones bringing the real revenue.
It's this one. If you're in a position to refund a "cost accident", then clearly you don't have to enforce cost controls in real time, and the problem becomes much easier to achieve at billing cycle granularity; the user setting a cost limit is generally doesn't care if you're a bit late to best-effort throttle them.