Depends - if your profits increase in line with your expenses, you might be raking in the ad revenue/views/sales/whatever because your product 'went viral' and you might prefer to keep it up.
Or if the rise in costs is something you can mitigate on your end - such as a bad deployment - you might want time to respond yourself, rather than your site going offline.
More generally, few site reliability engineers are looking to add extra ways for the site to be taken offline.
Of course, if you're large enough to be in those situations, your round-the-clock operations staff will be monitoring the billing situation as carefully as they monitor page load times and error rates and database load so an unexpected bill will be very unlikely.
> More generally, few site reliability engineers are looking to add extra ways for the site to be taken offline.
SRE 101 is rate limiting everything and protection against DDoS. With cloud and auto scaling risks of DDoS are less about uptime but more about getting a bill that will bankrupt the business.
> few site reliability engineers are looking to add extra ways for the site to be taken offline.
Apart from the cases already mentioned in sibling comments, at some scale you start adding in outage switches in many cases. Basically quick ways to take parts of your service offline if something starts misbehaving.
Google doesn't have good enough billing systems to be able to guarantee to be able to limit your spend. Lots of billing things are only done daily for example, meaning you could spend millions of dollars before the billing run at the end of the day.
Google prefers you be on the hook rather than them.
Google themselves recommend using the limits like max instances to mitigate the risk of out of control costs.
I also don't understand why this is being framed as a uniquely Google problem. Other cloud providers with serverless services have similar hazards and similar methods to manage the risk.
