New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
The provider has definitely a habit of claiming something which may not be true exactly. They mentioned that they emailed me about sustained cpu usage last year and then this year but I cannot see any emails and nothing in the panel messages about any warnings whatsoever. And then the cancellation/termination without the opportunity to take backups. I understand their point about FUP having a trust principle in it and they don't want to actively monitor neither have inclination to inform users automatically in such transgressions but then trust goes both ways. If someone was running 7 instances on your platform and most of the time they were idling since an year or so, how fair is to terminate 5 of them in an instant without giving any opportunity to explain things (or even take backups?).
Why didn't they just throttle the VPS rather than terminating it?
I was/am on the texas node, no issues as of yet, but I do do clean reinstalls of debian 13 and not use the template images.
Clean installs are easier than most people think, and then you don't have to worry about nasty preinstalled nonsense. Plus, you know all your systems are identical and that you're using Debian 13, not "provider's specific Debian 13 template". The only downside is that you sometimes have to make sure that you run
chattr +i /etc/network/interfaceswhen using Virtualizor because it will literally reach into your filesystem and edit that file, and it always assumes old-style interface names (like eth0).Funny, one of the first things i do is switch back to old style interface names, you'll pry my eth0 from my cold, dead hands!!
Frankly no idea. I can post my message to them explaining what was happening at my end (I am running domain screenshot project and had ai agent managing my fleet). They saw some sustained cpu usage on a vps and terminated it (once again reiterating without warnings whatsoever). Now because of this termination other vps in the fleet picked up the remaining load and their cpu usage hiked and it keep happening due to the domino effect until all vps running the screenshot workers got terminated one after another in few hours time.
Same here. Do not buy c-servers.
If you are still using c-servers, just use paypal dispute to get your money back before it's 2 late.
Same here, didn't get any notice email either
Just realized the post I saw on Reddit yesterday was actually you who posted it
Frankly out of my understanding why someone would terminate something and then waste time/resources etc. to justify the termination when it could be much simpler to just suspend and tell, hey boss, you have violated so and so policy and as such we cannot have you host this here further. You have 2 days time to take your backups and we will be terminating it after that. Like why this constant firefighting and justifying terminations left,right and center.
@openid Yes, hi
agree with u, they are always too arrogant
any othor tl;dr?
Hi everyone
I’m making this post to "self-expose" as the troublemaker who allegedly violated terms of service on a NAT VPS I recently purchased. At least, that’s how the provider sees it. Personally, I think there’s a massive gap between running standard management tools and "abuse."
Below is the email content:
My 2026/03/28 15:36
c-Servers Customer Service 2026/03/28 15:36
╔════════════════════╗
║ C-Servers ║
╚════════════════════╝
C-Servers 2026/04/09 07:23
My 2026/04/09 14:15
My 2026/04/09 14:38
Just noticed, most of these vps were ordered and running since July, 2024. Jan/Feb this year was when they were being used as part of screenshot project and 5 got terminated on first week of march. So barely 1 or 2 months of sustained cpu usage can get your vps terminated without warnings and chance to take backups even though you have been running them close to 2 years.
That's a classic cascading failure. It's always best to plan for those whenever you have multiple systems sharing a load.
So yes, am learning from this incident. So now I am going through tos/fup more properly since I have ordered much more vps from the other providers here as I scale things and have already a mechanism in place to make sure the load is reasonable as per the fup (and reducing them across the fleet so that each vps gets a breathing room). Also as I understand things how to manage multiple loads, I hope the fleet management will become more proactive and will avoid things like this in future.
Even with a cascading failure, a provider would be expected to ask you what's happening at best, and temporarily suspend the VPSes until they get an answer at worst. Straight-up terminating them without warning? That's nasty.
That is the problem. They don't ask but just presume things. In my case they emailed me this but when I asked specifically where is the prior warning emails, they couldn't share anything but just a vague message from Tiago that he remembers sending me an email. What the hell is remember sending an email which I can neither see in my mailbox nor see in the provider messages in the panel itself.
Have been consistently surpassing the fair share for the existing CPU, creating unnecessary performance issues for the users at this server, which is a violation of the Fair Usage Policy and of the existing fair-share (50% per vCore). All servers were well above this sustained fair share, with extra percentages up to 25% aggregate.
Since this is more than one server, and all of them are with the same user, it is unreasonable to presume that the issue is non-intentional. Moreover, these servers are with C-Servers for quite some time and you have been warned before for similar transgressions before.
Therefore, considering the volume in question, and the fact that you already had previous experience with our services and previous transgressions to account for, we have unilaterally terminated these three services and we are issuing you a formal warning for all of the remaining services - any similar abuses on these other services will render service termination for them as well.
Holy. Shit.
So they just straight-up assumed it was intentional and that there could be no other possible explanation of sustained CPU usage than malice?
Yes, and that too with just a month or two of heavy usage on servers which were with them since 2024. That is the way these folks roll. Here is the full and final email from Tiago.
Hello,
Answering some of the questions:
The Fair Use policy has a trust principle in it. We don't issue direct warnings when a CPU goes over the limit even if briefly because we understand that punctually a (small) level of usage above the fair use could happen. Another thing: we do checkpoints between measurements. Suspensions only occur with at least two moments, and cancellations only occur starting from three measurement moments (internal policy to determine course of action).
In your specific case, the warnings issued were last year when it was still on the SolusVM system. Nevertheless, I personally monitor the systems and I did attest, for much more than once, that some of your VPS services were sustainedly near or over the fair share, and I even recall sending a warning e-mail before to this particular e-mail.
I've personally seen this effect on the dedicated server: 2 servers were overusing the fair share, with the aforementioned CPU loads. When these two were cancelled (i.e. were down), two others, which were already working, increased their CPU loads to the same percentage; after these two were cancelled, a 5th suddenly increased the load, and only after this last one was cancelled as well, things went back to normal on the dedicated server. I don't see which type of usage they're getting for privacy purposes - all I see is CPU load, and the behaviour of CPU load (if it is e.g. consistent, occasional, inconsistent but frequent, etc), and then decide to act if it goes over the limit.
It is important to state that the CPU was not even near the maximum usage, or it could have been due to it - I'm fair on the measurements. In fact, more than once, I've allowed a slight overusage, for some customers that I knew were doing e.g. professional work, and that need the capacity.
That does happen, but those customers notify the company beforehand on what they're doing and why does it require some added tolerance, and then we either accept the usecase, or state it is not possible to have it on the servers, depending on the type of usage and also on reasonable CPU availability (because of course no one wants to use a CPU in such a way and have it perform slowly).
We do not presume malicious intention on the VPS usage as a standard purpose - we can't presume on one or the other way, the VPS usage is always private to the customer, a provider by default is neutral. However, since this happenned massively (after all, a total of five VPSes were caught on the issue), and since we had connections with prior e-mails, we had to go harder this time.
I do understand the type of usage intended, but unfortunately, the decision is indeed final on not restoring the services. This only goes for those five VPS services, though - we could have gone even further and block or blacklist the account if we saw malicious usage patterns, but with two services were working correctly and with no signs of these, we provided this added tolerance. Managing a dedicated server is a strict business, very rarely is this possible. I've personally provided the exception before for users with 1/2 VPS servers, but considering five were caught with the issue, I can't really do it here.
I'll take into consideration if it is possible to have communication from the VirtFusion's API or the QEMU process elsewhere for an automated warning to be issued, but this will be just an extra convenience to the existing Fair Usage trust policy, and will not replace the present management measures, which are manually held. We'd be having a lot of tickets if any significant CPU overusage went with performance throttling or iowait like some providers - it's simply not effective.
Our VPSes tend to have low iowait because management on the dedicated servers needs to be like this - and need to be strict on all fronts, including on this one. After all, you can't get more performance than bare metal, so we need to have customers operating at less than the existing bare metal capacity.
This ticket is marked as Resolved. Hope it was clearer to you now why we had to do what we had to do - no hard feelings on us, and from now on, kindly ensure the Fair Use is seen on the VPS usages.
Btw they had created and recreated the vps so many times when they were transitioning from SolusVM but I still ignored that since I understood and not expected much from such a budget vps provider but as I said earlier, trust goes both ways. If a buyer is trusting a provider in times like that, the same is expected back when something maybe wrong at our end.
Then my account got banned out of nowhere. If the network is already having issues, seeing a high volume of SYN packets is actually quite expected. I seriously doubt the provider's technical competence. Best to just file a PayPal dispute and get a refund ASAP.
Yea initially I thought this was just a scam operation but the more this thread continues and I see the provider's comments and proclamations I'm now leaning towards Hanlon's razor.
I mean how the fuck do you manage to aggregate so many bad actors on a single server that you end up with 34 vms portscanning the universe? It just doesn't pass the sniff test.
The server might either be hacked or badly configured, allowing you to hijack IP addresses temporarily, abuse them, and then watch the “owner” get blamed while you eat popcorn.
@zed
Actually, based on my own SSH port scans, the number of banned users likely exceeds 100. Before this incident, there were over 200 active SSH ports on this node; now, there are fewer than 30. This looks like a mass purge.
I didn't understand why they refund after KYC why not before KYC ??
I love reading the comments here; I am literally checking this thread every hour now. It has become an addiction! 😂
Even if I never managed to get a working VPS out of this provider, I feel like the money I spent was just a ticket for an interactive, live e-book experience! Worth it. 🍿🐢
Since the provider didn't keep the proper logs, they have absolutely no idea who the actual culprits are. So their logic is basically: 'Anyone who refuses to verify their ID (KYC) must be the guilty one