I am not writing this as a negative review of REGXA, and I am not trying to tell anyone whether they should or should not buy a VPS from them. This is simply one of my days as a developer.
I moved a normal workload onto a KVM VPS with 2 vCPU, 2 GB RAM, and 60 GB NVMe. Nginx was running. The backend was running. But the machine behaved as if it were massively overloaded: requests accumulated, TLS operations became slow, connections stayed open, and some requests eventually took more than two minutes before returning HTTP 504.
The CPU accounting changed the investigation
My first assumption was obvious: something inside the VPS was consuming the CPU. Then I ran mpstat.
Average CPU steal: 92.58%
CPU 0 steal: 90.62%
CPU 1 steal: 94.57%
CPU user: 4.02%
CPU system: 1.47%
CPU iowait: 0.41%
CPU idle: 0.53%Individual samples repeatedly showed roughly 89–98% steal. CPU pressure was also extreme:
CPU PSI some avg10: 79.47
CPU PSI some avg60: 75.32
CPU PSI some avg300: 76.31
Load average: 5.85 / 5.75 / 5.73This was a two-vCPU machine. Linux had runnable processes waiting for CPU, but the important number was not normal application CPU usage. It was %steal.
High CPU usage and CPU steal are different problems
If my application were actually burning the processor, I would expect high user or system CPU time. Instead, the VPS looked roughly like this:
user: 4%
system: 1%
steal: 93%CPU steal is time when a virtual CPU is ready to run but the hypervisor does not schedule it. So when I say CPU time was being taken away from the VPS, I mean it in that technical virtualization sense. I cannot prove that REGXA deliberately reassigned physical cores that belonged exclusively to me, and I cannot infer intent from guest metrics. What I can prove is that the guest repeatedly had work ready and was not receiving CPU scheduling time.
I removed all production traffic
There was still an obvious objection: maybe my workload itself was somehow causing the problem. So I removed that variable. I moved the active workload elsewhere, stopped production traffic to this VPS, let the request queues clear, and repeated the same CPU measurement.
Average CPU steal: 94.17%
CPU 0 steal: 95.56%
CPU 1 steal: 92.83%
CPU user: 1.95%
CPU system: 0.59%
CPU iowait: 0.59%
CPU idle: 2.18%The result became worse. Individual vmstat samples still showed 91–98% steal, and as many as 15 runnable processes were waiting for CPU. The key combination was:
user: 1.95%
system: 0.59%
steal: 94.17%My applications were now doing almost nothing, yet the VM was still losing almost all of its scheduling time. Normal production load was no longer a credible explanation.
Even localhost became absurdly slow
I also tested HTTPS through 127.0.0.1, removing public DNS, my ISP, geographic distance, and the external network path from the test.
Under traffic, four out of ten localhost HTTPS attempts failed during the TLS handshake. The successful requests took 29.30, 22.77, 12.25, 11.87, 11.12, and 9.40 seconds. Some TLS handshakes alone took roughly nine seconds.
After production traffic was removed, localhost improved but remained unstable: 0.061, 0.745, 0.830, 0.873, 1.010, 1.117, 1.121, 2.188, and 3.355 seconds. The same local operation could take about 61 ms once and more than 3.3 seconds the next time.
The rest of the stack showed the consequences
At one point I observed roughly 450 established connections, 122 orphaned connections, 110 FIN-WAIT-1 connections, and 33 CLOSE-WAIT connections. The localhost backend listen queue reached about 14–15, while the HTTPS queue reached about 40.
Nginx logged HTTP 504 responses after 142.857, 138.902, 135.064, 129.819, and 128.657 seconds. Other requests remained open for roughly 67–130 seconds. I also saw secure-connection timeouts around 35–41 seconds, database network timeouts, and delayed TLS operations.
Those symptoms could easily look like separate Nginx, database, networking, or backend problems. But increasing timeouts would not create CPU time that the hypervisor was not scheduling.
RAM and disk did not explain it
The VPS still had roughly 1.0–1.1 GiB of available RAM, almost no swap usage, no OOM events, and no OOM-killer activity. The filesystem was only about 20% full, with roughly 44 GB available. I/O wait stayed below 1% during the important CPU measurements.
The machine was not out of memory, the disk was not full, and my applications were not consuming the missing CPU. The dominant metric remained %steal.
A healthy KVM VPS looked completely different
I ran the same type of diagnostics on another KVM VPS that was actively serving normal traffic:
Average CPU steal: 0.02%
CPU idle: 87.86%
CPU PSI avg10: 0.29
CPU PSI avg60: 0.63
CPU PSI avg300: 0.49
Load average: 0.47 / 0.33 / 0.14Its ten localhost HTTPS requests completed between roughly 37 and 69 ms. I later measured another production VPS that was genuinely busy and saw 61.71% user CPU, 5.08% system CPU, 24.09% idle, and only 0.13% steal.
That is the distinction I care about now. A busy VPS can be slow because my software is actually using the processor. That is very different from a guest spending more than 90% of measured CPU time waiting for the hypervisor.
REGXA eventually confirmed infrastructure contention
From inside the VM I could measure the guest, but I could not see the physical host, scheduler configuration, CPU quotas, or neighboring VMs. REGXA could.
Support eventually told me that the VPS was hosted on shared CPU infrastructure, that CPU resources were shared among multiple virtual machines, and that performance could vary with load on the physical node. They also said the Frankfurt infrastructure was experiencing particularly high demand and explicitly attributed my elevated CPU steal to resource contention on the underlying infrastructure.
They said they could not change CPU quotas or scheduling policies or dedicate additional CPU resources for that shared VPS on the current infrastructure. Their proposed technical solution was relocation to a location with lower utilization.
This was difficult to reconcile with the product language I had seen around dedicated CPU cores and guaranteed resources. I cannot see the exact host configuration, so I cannot say whether the immediate mechanism was CPU overcommitment, quotas, scheduler weighting, throttling, or some combination of those. I also cannot prove intent. I do not need to: Linux showed sustained 92–94% steal, and REGXA itself attributed the elevated steal to contention on its shared infrastructure.
Getting the refund required another round of persistence
Once the infrastructure problem was clear, I did not want to keep relocating the VPS and testing other nodes. I wanted to cancel it and get my money back.
Initially, I was offered only a partial amount, and the proposed refund was to my REGXA account balance rather than back to the card I had used to pay. I did not consider provider credit equivalent to a refund when I was trying to leave the service.
So I kept replying and asking for 100% of the payment to be returned to the original payment method. Eventually, REGXA agreed and refunded the full amount back to the original payment method, describing the full refund as an exception.
I appreciate that they ultimately returned everything. But having to keep pushing for the financial resolution after support had already acknowledged the infrastructure contention is also part of my experience.
The lesson I kept from this
The easiest mistake would have been to keep optimizing my application. I could have changed Nginx settings, increased timeouts, reduced concurrency, added retries, investigated MongoDB, or rewritten backend code. Some of that might have changed individual symptoms. None of it would have answered the important question: why was CPU steal above 90%?
I no longer stop after confirming that SSH works, Nginx starts, and a health endpoint returns 200. On a new VPS I also look at %user, %system, %iowait, %idle, %steal, CPU PSI, the run queue, and localhost latency.
And when something looks suspicious, I remove the workload and measure again. In this case that produced the clearest result of the entire incident:
CPU user: 1.95%
CPU system: 0.59%
CPU steal: 94.17%I am not claiming that every REGXA VPS behaves like this. I tested one VPS and documented what happened to it. But on that VPS the evidence was unusually clear: my applications were barely consuming CPU while Linux reported that the overwhelming majority of virtual CPU time was being lost to hypervisor scheduling. REGXA later attributed exactly that behavior to resource contention on its shared infrastructure.
That is why I am documenting it. Not as a score or a recommendation, but simply as one of my days as a developer — and one metric I will never ignore on a VPS again.