Persistent VM Freezes and Disappointing Support
We purchased five Linux VMs totaling 52 vCPUs and 5 TB of storage. These systems are lightly loaded, averaging less than 0.75 load, yet every VM has experienced Linux kernel RCU stalls and clocksource long read warnings.
These events cause the VM to freeze for 3 to 50 seconds, resulting in dropped database connections, failed HTTP requests, interrupted SSH sessions, and customer downtime. Some VMs experience this multiple times per day.
Atlantic.Net support was initially responsive and tried a few configuration changes, but nothing resolved the issue. Eventually the problem was dismissed because they could not reproduce it, communication stopped, and even after escalating to their Director of Support, I never received a response.
Despite advertising a 100% uptime guarantee, Atlantic.Net does not consider these freezes to be downtime because the VM itself remains running. From a customer's perspective, however, an unresponsive VM is effectively offline. Their final response was that they found no evidence the issue was caused by their infrastructure, even though the kernel traces consistently show the guest vCPU entering an idle state and not being scheduled again for the duration of the stall.
We also experienced other reliability issues during our relatively short time with Atlantic.Net. There was a major network outage affecting an entire data center for several hours, and another incident where a cloud host suffered a storage backplane failure. All VMs on that host had to be restored from backups taken the previous evening, resulting in nearly a day's worth of data loss and another almost entire day of downtime for affected customers.
It also appears that Atlantic.Net does not maintain on-site personnel at many of its data centers. As a result, when significant hardware failures occur, systems often cannot be repaired in place and customer workloads must instead be restored onto replacement hardware, increasing downtime and the potential for data loss.
Overall, the infrastructure has not been reliable enough for production workloads, and after months of troubleshooting we were left without a meaningful resolution. That's unfortunate because we had high hopes for Atlantic.Net. We understand that every hosting provider experiences occasional infrastructure problems, but repeated VM freezes are not something we can overlook.
RESPONSE TO THEIR REPLY:
It is true that we used a custom ISO. However, it was simply a stock Debian 13 ISO with no changes to the kernel, boot configuration, or kernel configuration. We even compared our configuration against Atlantic.Net's own ISO to confirm there were no material differences. The only reason we used it was to install XFS as the root filesystem, a mature and widely used Linux filesystem commonly deployed for PostgreSQL and other database workloads.
Blaming the custom ISO also does not fit the evidence. We had four VMs organized into two clusters of mirrored, load-balanced servers. Within each cluster, the VMs ran the same OS and configuration, shared the same production traffic, and were each located on separate bare-metal hosts. All four experienced stalls, but at dramatically different frequencies. One experienced them daily, sometimes multiple times per day, while its mirrored counterpart experienced them only once or twice per month.
We also tested booting with the Linux idle=poll kernel parameter, which effectively prevents the CPUs from entering normal idle states. The stalls immediately and substantially decreased, although they were not eliminated completely. Combined with the dramatic difference between otherwise identical VMs on separate physical hosts, this further points toward the underlying virtualization or host infrastructure as a factor that warranted serious investigation.
None of this conclusively proves the exact root cause, but simply blaming a stock Debian ISO does not adequately explain the evidence. If using a stock Debian ISO solely to install XFS puts a VM outside what Atlantic.Net is prepared to troubleshoot, then in practical terms they are saying they cannot fully support a very common Linux configuration for production PostgreSQL workloads.
To Atlantic.Net's credit, they initially communicated with us and made some attempts to investigate. However, once we had migrated the majority of our production environment to their platform, meaningful communication with their technical staff effectively stopped. Despite repeated assurances that knowledgeable technical personnel would contact us, that did not happen.
Reply from Atlantic.Net, Inc.
Thank you for sharing your feedback. We are sorry to hear that your experience did not meet your expectations.
We do want to provide some important context for others reading this review. The VM behavior described was taken seriously and reviewed extensively by our team. However, based on the information available during that review, the RCU stall behavior appeared isolated to this customer’s virtual machines and was not observed as a broader issue across other customers, environments, or the Atlantic.Net platform. We were also unable to reproduce the behavior using Atlantic.Net-provided operating system images or ISOs.
The customer’s environment was deployed using a custom ISO provided by the customer, rather than a standard Atlantic.Net image. While RCU stalls and guest-level freezes are not behavior we consider normal or acceptable, the presence of those errors inside a guest operating system does not, by itself, confirm a hypervisor, infrastructure, or platform-level failure. To classify an issue as an Atlantic.Net service reliability issue, we need supporting evidence tying the condition to Atlantic.Net-managed infrastructure. In this case, we did not identify that evidence.
We also disagree with the characterization that the matter was simply dismissed. Our team reviewed the reports, made configuration adjustments, evaluated the available evidence, and addressed the matter directly in correspondence with the customer. We understand the customer remained dissatisfied with the outcome, but the conclusion was based on the evidence available to us, not a lack of concern.
At Atlantic.Net reliability is always a core focus. When infrastructure incidents occur, we investigate them, communicate with affected customers, and take corrective action where appropriate. At the same time, it is important to distinguish between confirmed platform-level issues and guest-specific behavior that cannot be reproduced across our platform or tied to Atlantic.Net-managed infrastructure.
We regret that this customer’s experience did not result in a better outcome and remain committed to providing reliable infrastructure, responsive support, and careful review when customer concerns are raised.
