High CPU but Low Traffic? The Hidden Processes Draining Your VPS
A field guide to finding CPU spikes that are not caused by user traffic, from background jobs to agent misconfiguration.
- Dataset size: 1,257 plans across 12 providers. Last checked: 2026-01-28.
- Change log updated: 2026-02-16 ( see updates).
- Latency snapshot: 2026-01-23 ( how tiers work).
- Benchmarks: 60 run(s) (retrieved: 2026-01-23). Benchmark your own VPS .
- Found an issue? Send a correction .
High CPU but Low Traffic? The Hidden Processes Draining Your VPS
“CPU is at 95%, but traffic is normal.” This is one of the most common VPS incidents in small teams.
The root cause is often outside the request path: scheduled jobs, logging storms, broken retries, backup tools, or monitoring agents configured too aggressively.
First 5-minute diagnosis
Run:
toporhtopfor active process viewps -eo pid,ppid,cmd,%cpu --sort=-%cpu | head -20uptimefor load context
You are looking for a process owner and pattern, not a perfect explanation in minute one.
Common hidden offenders
- Cron jobs that overlap after delays
- Log processors in infinite retry loops
- Security scanners running full sweeps during peak
- Misconfigured monitoring exporters with expensive collectors enabled
- App workers stuck on hot loops after dependency failure
Most teams find the issue in this list before touching kernel tunables.
Check retry and queue behavior
CPU spikes with low external traffic can still be internal “traffic”:
- dead-letter replay storms
- queue consumers retrying failed tasks too fast
- webhook redelivery loops
Inspect queue depth and retry counters before blaming infra.
Contain first, optimize second
Immediate containment actions:
- pause non-critical workers
- disable heavy optional collectors
- cap worker concurrency temporarily
- isolate and stop obviously runaway tasks
Once stable, fix root policy:
- backoff strategy
- task idempotency
- cron lock discipline
- alert thresholds tied to business impact
Prevention baseline
Set three proactive controls:
- Alert on CPU + process-name correlation, not CPU alone.
- Track scheduled task durations and overlaps.
- Require rollback path for any new background worker.
This turns repeat incidents into one-time lessons.
Final takeaway
High CPU without traffic usually means “work is happening somewhere else.” Treat background execution paths as production-critical systems, and these incidents become far easier to prevent.