[inopinatus]

Sure, it's reasonable, if your desired outcome is to lose a customer by

a) demonstrating a lack of burst or headroom capacity and/or graceful degradation/priority scheduling capability, and

b) being a dick about it.

Alternatively one may intervene with a positive approach and framing viz. "we have temporarily [provisioned additional capacity / relocated your storage to another spindle / mirrored your content to a less congested host / etc] in order to handle your traffic, can we call you tomorrow to move you to a service plan that can handle your growth". Even just throttling the account in some appropriate fashion would've been better than the blunt "we dropped you like a hot potato" that was actually communicated. This was in 2010, by which time any ISP that wasn't operating as amateur hour had the tools for all these things.

[oarsinsync]

> This was in 2010, by which time any ISP that wasn't operating as amateur hour had the tools for all these things.

Agreed. Also consider that shared hosting packages are very much providers scraping the bottom of the barrel for some marginal extra revenue. Shared hosting customers are not the highest priority of customers, unless your entire business is based around shared hosting (in which case, you are likely operating as amateur hour anyway)

[taskforcegemini]

depends on what product/service plan they had. a 5$ per month is not worth jumping through the hoops, because usually an individual solution is needed, but this doesn't scale. if the site is important to the owner, they need a more fitting service plan with higher headroom. that being said, a good provider at least tries to filter out what could be a (d)dos

[stackskipton]

In 2010, those tools were not easily available outside massive Enterprise solutions like Akamai. Cloudflare just launched in 2009 and on-premise hardware was generally cost prohibitive.

[inopinatus]

I was building ISPs from the 1990s. The idea that after decades of innovation and field experience, tools for managing bursty/high-growth customers were somehow "not easily available", or that hardware be some kind of unicorn resource, just smells to me like rank incompetence. In this case coupled to an equally questionable customer retention failure.

[ajb]

In many industries it's standard practice to cause pain to one customer to avoid causing pain to all of them. If you've ever had work done on your house, a small guy who overruns will often bail out on your job ( and reschedule) rather than slip all the other customers he had lined up. so I can see why this guy decided to disable a directory rather than all the other customers in the server have slow service

The issue is that the economics are different: a roofer doesn't earn more by doing one big job than 4 small ones in the same time. But a big user is a better economic prospect to a service provider than the small ones. That's why this was clearly a dumb move