Can You Run a VPS at 100% CPU? The Answer Is in the Product Name
People ask this expecting a number — 80%? A rolling average? A weekly quota?
There isn’t one. We went looking for a CPU threshold in providers’ terms and found something more useful: the answer is built into which product line you bought, and the vendor states it plainly in the plan description.
Hetzner says it out loud
Read how Hetzner describes its two cloud lines, in its own words on its own page:
| Shared Resources | Dedicated Resources | |
|---|---|---|
| Sold for | “Low to medium CPU usage” | “Constantly high CPU usage” |
| Traffic | “Medium traffic applications” | “High-traffic applications” |
| Positioning | “Inexpensive due to shared resources” | “Optimized for business applications” |
| Suitability | “Perfect for test environments” | “Unshared performance and highly predictable resources” |
And the sentence that settles it, from the same page:
“Shared cloud plans… are designed for variable usage patterns rather than sustained high workloads.”
That’s not a hidden clause. It’s the product description. If you bought a shared-vCPU plan and you’re planning to pin it at 100% around the clock, you’ve bought the wrong line — and the vendor told you so before you paid.
On a dedicated-vCPU plan, sustained 100% is literally what you’re buying. “Constantly high CPU usage” is the stated use case.
What the contract actually says
We read Hetzner’s terms and conditions looking for a CPU clause. What’s there is general:
“The Customer is obligated to use the services provided appropriately and to refrain from abusive and illegal actions.”
No percentage, no duration, no rolling average. That’s typical of this market, and it’s why articles quoting specific thresholds should be treated with suspicion — they’re usually describing one provider’s support behaviour rather than a contractual term.
So the operative framework is two things, neither of which is a number:
- A general appropriateness obligation in the terms
- A product taxonomy telling you which line is designed for sustained load
The second is the one you can act on.
Why shared vCPU throttles and dedicated doesn’t
The mechanism, briefly, because it explains the policy.
On a shared-vCPU plan, your virtual core is scheduled onto a physical core alongside other tenants. The economics assume most customers are idle most of the time — that’s what makes the plan cheap. A tenant running flat out consumes what the overcommit model assumed would go unused, and the host’s options are to let everyone else degrade or to intervene.
On a dedicated-vCPU plan, physical cores are assigned to you. There’s no one to take capacity from, so there’s nothing to police. You paid for the core; running it at 100% is using what you bought.
The practical signal that you’re on an oversubscribed host is CPU steal time — the percentage of time your vCPU was ready to run but waiting for the physical core. We covered how to measure it, and it’s the number to check before blaming your own code.
Which workloads actually need the dedicated tier
The distinction only matters for genuinely sustained load. Most things aren’t.
Fine on shared vCPU:
- A web application, even a busy one — traffic is bursty and idle between requests
- An AI agent calling a hosted model API — it waits on the network, not the CPU
- n8n or a scheduler firing workflows periodically
- A Discord or Telegram bot holding a connection
- Almost anything where the CPU spikes and returns to idle
Needs dedicated vCPU:
- Video transcoding, which pins every core for the duration
- CI/CD build runners doing back-to-back compilation
- Local model inference on CPU — the Ollama case, where the whole point is sustained computation
- Game servers with a tick loop that must not miss
- Anything you’d describe as “it runs constantly”
The honest test: look at a week of your CPU graph. If it’s a flat line near the top, buy dedicated. If it’s spiky with troughs, shared is what it’s for — and you’d be paying a premium for capacity you don’t use.
What it costs to be contractually safe
Dedicated cores cost more, and how much more varies by provider. At Hetzner, its dedicated CCX line runs roughly $5.80 per gigabyte of RAM against $4.86 on the shared CPX line — but the per-gigabyte comparison understates it, because the reason to buy dedicated is the cores rather than the memory. Across the market, dedicated-core plans typically run two to three times their shared equivalents at comparable specs.
That premium is the price of not having a conversation with your host. For a transcoding box or a build runner it’s straightforwardly worth it. For a web app that idles between requests, it’s money spent on a guarantee you’ll never need.
The providers
Hostinger — shared vCPU across its KVM range at $11.99 renewal for 4GB and $14.99 for 8GB, which is the right buy for bursty workloads and the cheapest way to get there. For sustained full-load work, size up rather than assuming the entry tier absorbs it — and check your own CPU graph before deciding you need more.
Hetzner — the clearest labelling in the market, splitting Shared Resources from Dedicated Resources and stating the intended CPU profile for each. Its dedicated CCX line is the explicit answer if you need sustained 100%. Note the 2026 repricing and that its cheap shared tier has been unavailable.
DigitalOcean — separates Basic (shared) from CPU-Optimized and General Purpose (dedicated) droplets, with the same underlying distinction under different names. $24 for 4GB on Basic; the dedicated tiers cost substantially more, which is the point.
UltaHost — more cores per plan than most at $15.87 for 4GB with 3 vCPU, and its two-year rate is also its renewal rate. Good value if your workload is spiky and you want headroom.
Cloudzy — $17.37 for 4GB billed monthly with no term, which is the low-risk way to test whether your workload actually needs the dedicated tier before committing to one.
If you’re deciding between tiers, what a vCPU actually is covers the three levels and how to detect oversubscription, and dedicated CPU VPS covers which providers’ “dedicated” labels are genuine.
How we checked this
Hetzner’s product wording is quoted from its own cloud page, read on 18 August 2026: “Low to medium CPU usage” and “Inexpensive due to shared resources” against “Constantly high CPU usage” and “Dedicated vCPUs”, plus the fuller statement that “shared cloud plans… are designed for variable usage patterns rather than sustained high workloads.” That’s the load-bearing evidence in this article and it’s a vendor describing its own products, not our interpretation.
The terms-and-conditions quote — “The Customer is obligated to use the services provided appropriately and to refrain from abusive and illegal actions” — is from Hetzner’s published terms, read the same day. We searched that document for a numeric CPU threshold and found none.
We checked one provider’s terms properly, not five. The brief for this article asked for actual fair-use wording from several providers; we have Hetzner’s in full and have not read the equivalent clauses at Hostinger, DigitalOcean, UltaHost or Cloudzy. The characterisation of DigitalOcean’s Basic versus CPU-Optimized split reflects its published droplet taxonomy rather than its terms. Check your own provider’s wording — the article’s point is that the answer lives in the product description, which means it varies by provider.
We did not run any load test. The brief asked for measured behaviour under a 24-hour full-load test on shared versus dedicated hardware at the same price point. We have no VPS fleet to test on, and running sustained full load on a provider’s shared infrastructure specifically to document their response would be an odd thing to do to a host we recommend. So there are no throttling measurements here, and the article argues from stated product intent and the mechanics of overcommit instead.
The pricing is from our research across this series in August 2026, including Hetzner’s CCX23 at approximately $5.80 per gigabyte against CPX32’s $4.86 as recorded in our price index. The “two to three times” figure for dedicated-core premiums market-wide is the range established in our vCPU article rather than a fresh calculation.
What we did not do: contact any provider’s support to ask about sustained load, review any suspension notice, or verify what any host does in practice when a shared-vCPU customer runs flat out.
The host links above are affiliate links. The article’s conclusion is that most readers don’t need the more expensive tier and should check their own CPU graph before buying it.
FAQ
Is 100% CPU usage allowed on a VPS?
On a dedicated-vCPU plan, yes — that’s what it’s sold for. On a shared-vCPU plan the vendor generally isn’t selling it for that: Hetzner describes its shared line as being for “low to medium CPU usage” and “variable usage patterns rather than sustained high workloads.”
Is there a specific CPU limit in hosting terms?
We didn’t find one. Hetzner’s terms carry a general obligation to use services “appropriately” with no percentage or duration attached. Articles quoting specific thresholds are usually describing support behaviour rather than a contract.
What happens if I max out a shared vCPU?
The host’s overcommit model assumes most tenants are idle. Running flat out consumes capacity others were expected to use, so you may see throttling or contact from the provider — the specifics vary and we haven’t tested them.
Which workloads need a dedicated vCPU?
Video transcoding, CI build runners, CPU-based model inference and game server tick loops — anything you’d describe as running constantly. Web apps, bots and API-backed AI agents are bursty and fine on shared.
How do I know if I’m on an oversubscribed host?
Check CPU steal time — the percentage of time your vCPU was ready but waiting for a physical core. It’s the measurement that distinguishes a slow neighbour from slow code.
How much more does a dedicated vCPU cost?
Typically two to three times a shared equivalent at comparable specs. At Hetzner the dedicated line runs about $5.80 per gigabyte of RAM against $4.86 shared, though the memory comparison understates it since cores are the point.
How do I decide?
Look at a week of your CPU graph. A flat line near the top means buy dedicated; spikes with troughs between them mean shared is exactly what you’re paying for.
