All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
CloudCone St. Louis Datacenter Fails hard: VPS Dead 4 Days, Support Confuses LAX with St. Louis! (Ti
I am creating this thread to publicly expose the shocking level of incompetence and absolute negligence by CloudCone support staff regarding my Ticket #9239765.
My VPS is located in their newly launched St. Louis (ST. LOUIS - DC1) location. 4 days ago, the server went completely offline, and the VNC console became totally non-responsive. This is a 100% textbook case of a physical host node crash or a severe hypervisor failure in St. Louis.
Instead of assigning a technician to check the actual node, here is the ridiculous "circus" I've dealt with for the past 4 days:
Clueless & Blind Support: The frontline reps didn't even bother to check my IP or location. They repeatedly copy-pasted generic Los Angeles (LAX) migration alert templates to brush me off. Since when does migrating an LAX node cause a St. Louis server to die for 4 days?!
Lazy Solution: Their first instinct was to tell me to "rebuild" the server. I have critical, irreplaceable business data on that disk. Forcing a user to wipe their entire disk because of your own host node crash is unacceptable.
Eternal 18-Hour Wait: Every single basic response takes up to 18 hours. And after waiting almost a full day, all I get is a canned response from an agent who doesn't even know which datacenter my server is in.
Currently, the VPS is permanently trapped in a reboot loop from the panel, and VNC remains entirely dead.
I am posting this here because your internal ticket system is a complete joke. I absolutely REFUSE to rebuild or lose my data.
I demand a Senior Datacenter Manager or L3 Engineer who actually manages the St. Louis location to look into Ticket #9239765 immediately. Stop copy-pasting the LAX template. Check the physical host node, force reset my VM from the backend hypervisor, and save my data!
@Cloudcone
Has anyone else experienced this utter chaos with CloudCone's new St. Louis location?
Comments
I have to talk about this too. Ever since I got that St. Louis 6C 4G VPS on May 29th, my website service has hardly been stable. In May, there were issues with the server rankings—it would just randomly shut down once a week for no reason, and that happened twice. Then they told me it was a network problem. During that time, network latency was so bad every day that even in Los Angeles, right here in the U.S., it would spike to over 500 milliseconds. Then for most of June, right around mid-month, they told me it was "completely fixed." It stayed stable for about ten days, and I was quietly celebrating—only for them to pull this stunt again these past few days. Ha. And this time it's even more impressive—my data looks like it's about to go up in smoke.
too many report about them, why let don't ban their provider tag?
Because being in the low-end of low-end providers is not against the rules.
By which I mean they paid bilobucks.
Why don't you set backup for your critical data, especially VPS on this price?
Furthermore, your St. Louis Datacenter
= Cybercon
= QuadraNet
= Multacom
= EdgeCentres
= DigitalSpace
Don't expect any "Senior Datacenter Manager" or "L3 Engineer" will help you.
Check latest LEB news.
The thing is, my server backs up weekly to my own cloud drive. But of course, right before everything went down, I had just finished a major project and hadn't gotten a backup yet. Then I woke up the next day and the server was already dead.
Zero Backup == Zero Worth
Edit: Cloudcone requesting password?
OP keeps using a service he's saying isn't fit for service but didn't have backups. That's incompetence blaming others for their mistakes.
Shocking screenshots! still do the blame game.
did u backup your 'critical' data remotely/ daily?
why use lowend box for 'business' data in the 1st place?
for critical business data, i suggest you go for more reputable providers.
First, we'd like to sincerely apologize to @MEKLWH for both the temporary outage and how this case was handled.
The ticket #9239765 was escalated for review by our Support Team Manager, who took over the case to ensure it received the attention it deserved. It was confirmed that the affected Budget VPS was hosted in the St. Louis data center and that the issue was related to the underlying host node. Good news: the host issue has since been resolved, the VPS has been restored to normal operation, and the node continues to be monitored to ensure ongoing stability.
To clarify the confusion surrounding the support process. At the time, our support team was handling an unusually high volume of tickets related to a separate infrastructure event in our Los Angeles data center. As a result, this ticket was mistakenly associated with that incident despite being unrelated. While the unusually high ticket volume explains how the mix-up occurred, it should have been identified and handled correctly sooner.
We have addressed the handling of this case internally to improve our processes and ensure similar situations will be handled more appropriately in the future.
That said, it’s important to clarify our Budget VPS line is self-managed and does not include automatic backups by default. Users are responsible for maintaining off-site backups of critical data.
At the end of the day, absolute resilience comes from combining the right infrastructure with solid backup practices, and we’re focused on giving our users flexible options like SC2 (with auto-backups) that protect what matters most.
Also, if anyone is experiencing issues in St. Louis, please reach out to our support team with your VPS IP/hostname and any observations, and we will investigate it.
Thank you for your continued patience and feedback.
Luckily, after we put up that post, Manager Jaden managed to fix everything we talked about. My server is back and all data survived. Big thanks to LET, thanks to everyone in the community, and thanks to Jaden for being so patient with us.
@Cloudcone This appears very similar to the issue described in this thread, except my VPS is located in Los Angeles DC2 on node HS49.
My instance has been stuck in “re-booting”, every panel action returns “Instance is performing tasks”, and noVNC cannot connect to the downstream server. Despite repeatedly explaining that I cannot operate the VPS from the panel, support keeps sending generic network incident replies and asking me to reboot it myself.
A VPS that is not successfully running cannot have its connectivity tested. Please stop treating this as a normal network timeout and have an engineer check the actual VM and hypervisor task state on HS49, clear the stuck operation, and manually start or power-cycle the instance.
Please preserve the existing disk and data and do not rebuild the VPS.
Ticket: #0649566
The issue has been resolved, and my VPS is back online. Thank you.
Tagging @Cloudcone
Backups and snapshots are not working either.