All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
[Review] DeluxHost: 2+ Days of Node Collapse, 259ms Kernel Latency & Total Support Silence (Offer Z)
Hello LET community,
I wanted to share a technical review and warning regarding DeluxHost (deluxhost.net), specifically their Amsterdam budget line (Offer Z - 1 vCore, 512MB RAM, €6/year).
While we all understand that ultra-budget "Deals" come with limited support, what is currently happening goes beyond "unmanaged service"—it is a complete infrastructure collapse on their host node, paired with total radio silence for over 2 days.
Here is the timeline and the shocking technical data from the VNC console.
The Timeline
Day 1: The VPS ("charming-good") started disappearing and appearing randomly in the control panel. A service disruption notice appeared in the ticket: «hardware fault was identified within the affected rack...»
Day 2: Support acknowledged that the host node was in a critically degraded state, promising an escalation for force-migration or hardware intervention.
Now (Day 4): Total silence. No updates, no ETA, and the VM is trapped in a vegetative state on a completely broken hypervisor.
I performed a manual reboot from the control panel to see if it would temporarily restore anything, but the guest OS immediately choked due to extreme CPU theft on the host side.
The Technical Evidence (VNC Console Logs)
The host node is so starved of resources that it is breaking the fundamental physics of the Linux kernel inside the guest VM.
Absolute Core Timer Collapse (hrtimer up to 259ms)
The hardware is taking away CPU cycles for so long that a single internal kernel timer interrupt takes over a quarter of a second to process:
[ 2236.418290] hrtimer: interrupt took 259148229 ns
For comparison, a healthy server processes this in nanoseconds.Watchdog Gaps & Frozen Real-Time (3.9 to 6.8 seconds)
The hypervisor freezes the VM entirely for seconds at a time. The kernel watchdog continuously throws errors because the clocksource completely loses track of time:
[ 5323.714753] clocksource: Long readout interval, skipping watchdog check: cs_nsec: 3873670950
In previous sessions, this gap reached 6.8 seconds (cs_nsec: 6852414690).Hypervisor Communication Failure (AF_VSOCK)
The communication channel between the physical host machine and the guest OS has completely broken down. The console is flooded with:
systemd-ssh-generator: Failed to query local AF_VSOCK CID: Cannot assign requested addressNetwork Stack Paralysis
Because the VM is getting almost zero actual CPU execution time from the node, the Linux kernel cannot process socket garbage collection, resulting in a permanent loop of:
nf_conntrack: table full, dropping packet
The server is dropping 100% of all traffic because it’s starved of the CPU cycles required to clear its own buffers.
Conclusion
If you are buying a server from DeluxHost—even for basic proxy routing, hobbies, or lightweight development—be aware that if their hardware breaks, your data will be locked away in a frozen VM for days, and your tickets will be completely ignored once they run out of template responses.
They are fully aware of this node's status but seem to have zero urgency in resolving it or migrating the affected users.
Has anyone else on the Amsterdam/Offer Z nodes experienced this level of downtime recently?
Comments
how extreme? 99 st?
They are under massive DDoS attack
Pretty much, yeah. It’s actually so extreme that standard %st reporting in top completely breaks down because the guest clocksource itself is losing track of real time.
The host hypervisor is literally freezing the entire VM instance execution for seconds at a time. Here is what the VNC dmesg/console shows:
Total execution freezes: The kernel continuously drops clocksource: Long readout interval, skipping watchdog check with cs_nsec gaps ranging from 3.8 seconds (3873670950 ns) up to a staggering 8.3 seconds (8301617635 ns). The VM is essentially completely paused during these intervals.
Interrupt Latency: A single internal core timer interrupt (hrtimer) took 259ms (259148229 ns) to process because the host CPU refused to allocate cycles mid-execution.
Even the kernel's deadline scheduler is giving up: sched: DL replenish lagged too much.
So it's effectively 100% steal time during those massive stutter blocks. The node is heavily choking.
Look at the green line (TX) – it's dead weight at exactly 0 Mbps. This is precisely the result of network stack paralysis:
Penny service, premium expectations ...
Cheap doesn't mean you don't have to work at all...
I haven't been able to access SSH for two days now. The server simply isn't able to respond.
Loosing milions ?
At some point will start to work again... patience.
LOL, that's close to 90%. Maybe one of the vm was set with a 4-8G swap and the other vm OOMing.
My first post in the ticket was on June 8th.
CPU Steal:
The mpstat -P ALL 1 10 command shows catastrophic CPU Steal. The average %steal value is 96.68%, peaking at 98.53%. Our VM is completely depleted of CPU time due to an overcommit or a crash on the physical host. It's clear that neighboring virtual machines are completely consuming the node's resources.
And since then, things have only gotten worse.
Dear, you are paying 50 cents per month for a VPS, your expectations are to high. For sure a 50 cents VPS is a shit VPS on a overloaded hypervisor.
I fully agree that for €6/year, my expectations for performance should be rock-bottom. I bought this as a toy box, and I would be totally fine with high steal time, sluggish CPU, or bad network speeds. That’s the classic "low-end experience."
But there is a massive line between an overloaded hypervisor and an abandoned, broken node.
Overloaded means my scripts run slowly because neighbors are mining crypto.
Broken means the hypervisor literally pauses the guest environment for 8.3 seconds at a time (cs_nsec: 8301617635) and causes a 259ms internal kernel interrupt delay.
This isn't an issue of "cheap VPS performance"—this is a confirmed unaddressed hardware/rack fault that support acknowledged days ago and then went entirely MIA on. 50 cents or not, if the host machine is physically dying and a provider goes radio silent for 3 days, it’s a valid reason for a technical warning post.
Ok.
I keep my oppinion. Your expectations are way to high.
Have a good day!