Quick answer: Run top and look at the st column — sustained steal above ~2-3% means the hypervisor is making your vCPU wait behind other VMs. On Minecraft, /tps at peak hour tells the same story. We tell people to run these tests on us too.
What "oversold" actually means
A node has, say, 64 physical threads. A host can sell 64 vCPUs across VMs (honest), or 256 (oversold 4:1). Most of the time overselling hides fine — until 19:00, when everyone’s servers are busy at once and the physical cores become a queue.
Budget hosting lives on this trade-off: the headline price is real because the density is the product. The checks below expose it directly.
Test 1: CPU steal time on Linux
Steal time is the percent your vCPU wanted to run but the hypervisor made it wait for someone else’s VM. It’s visible inside your own server:
- Run
topand read the%Cpu(s)line — thestvalue is steal. - Sustained st ~0-2% = uncontended. Occasional spikes happen on any shared infrastructure.
- Sustained st above 5% at your peak hour = the node is oversold — your "dedicated" cores are a queue.
- Check it at 19:00-22:00, not at noon — overselling only shows under real load.
Test 2: Minecraft TPS at peak hour
For game servers the equivalent is TPS — ticks per second. A healthy Paper/Spigot server holds 20 TPS; an oversold node sags to 15-18 at peak even with few players online.
Run /tps (or Spark timings) during your busiest evening window. If TPS drops when your server is quiet but their node is busy, the problem is the neighbors.
Test 3: the honest timing comparison
The fairest check is timing the same workload at different hours: compress a file, run a benchmark, watch your Minecraft timings report. A dedicated resource performs the same at 14:00 and 21:00; an oversold one doesn’t.
Run it in your first days, while changing providers is still cheap — documented steal-time/TPS evidence is also what a billing or migration conversation should start with, numbers beat complaints.
What we do differently — and how to verify it
HostCraft nodes allocate vCPU and RAM dedicated per VM — no bursting into a shared pool. That’s a claim too, so check it the same way: deploy, run steal-time and TPS tests at peak hour in your first days, and hold us to the numbers. Our refund policy is public and blunt — provisioned services are non-refundable while failed provisioning refunds automatically — so test early, before you build on the box.
If a provider gets defensive about the test, that’s also data.
Related pages
- VPS & RDP plans — dedicated allocation from $2.59/mo
- Public status history — uptime you can audit
- Minecraft hosting India — dedicated-RAM game tiers
- KVM vs OpenVZ — the virtualization half of the story
FAQ
What is steal time?
The percent your vCPU wanted to run but the hypervisor made it wait behind other VMs — the direct symptom of node oversubscription, visible in top as the st column.
What steal time is acceptable?
0-2% sustained is normal on shared infrastructure. Sustained above ~5% at your peak hour means the node is oversold.
How do I check TPS?
Run /tps in-game on Paper/Spigot — 20 is perfect, 18-19 fine, below 18 at your own quiet hours means the node’s problem, not yours.
Can a host hide overselling?
From marketing pages, easily. From steal time and peak-hour TPS, no — that’s the whole point of testing inside the VM rather than reading specs.
What if my steal time is high?
Document it at peak hour over a few days, then either migrate or use it in the refund/ticket conversation — numbers beat complaints.