Monitoring VPS Resources and Avoiding Suspension

A VPS runs at the resource limits you’ve paid for — CPU cores, RAM, disk, bandwidth. Stay within them and your server hums along. Cross them sustainedly and you’ll see degraded performance, throttling, or in extreme cases, suspension. This guide covers how to see what your VPS is actually doing, identify the cause of any spikes, and stay on the right side of your plan limits.

What gets measured

• CPU — how busy your processor is. Sustained high CPU (90%+ for hours) means a process is hot or you need more cores.
• RAM — memory in use. Once full, the system “swaps” to disk, which is slow. Constant swapping = need more RAM.
• Disk space — how much storage is used. Hitting 100% is a hard failure — nothing can be written, services start crashing.
• Disk I/O — read/write operations per second. High I/O bottlenecks can slow a site even when CPU and RAM look fine.
• Bandwidth — total inbound + outbound traffic. iWebVault VPS plans have a monthly bandwidth allowance; exceeding it triggers either throttling or overage charges depending on plan.

Quick health check (one command)

SSH into your VPS, run:

top

You’ll see a live dashboard. Pay attention to these lines:

• Load average (top right): three numbers — 1-minute, 5-minute, 15-minute averages. Rule of thumb: load < (number of CPU cores) = healthy. Load = 2× cores = busy. Load = 5× cores = problematic.
• %Cpu(s) — current CPU usage breakdown. us is user processes, sy is system, id is idle, wa is waiting on I/O (disk). High wa means disk bottleneck.
• MiB Mem — total / free / used / buff/cache. Linux uses “free” memory for caching; real free memory is “available”.
• Process list below — sorted by CPU. The top process is what’s working hardest.

Press q to exit. For a more readable view:

htop

Install with apt install htop (Debian/Ubuntu) or dnf install htop (AlmaLinux/Rocky). htop is the same data prettier — colored bars per CPU core, tree view of processes (F5).

Disk and I/O

Check disk space:

df -h

Shows each mounted filesystem. The line for / is your main disk. Watch the “Use%” column. Anything over 80% deserves attention; over 95% is urgent.

If disk is filling unexpectedly, find what’s eating it:

du -sh /var/* | sort -rh | head -20

Shows the 20 biggest things under /var/ (where most logs and databases live). Common culprits: massive log files in /var/log/, MySQL data in /var/lib/mysql/, email queues in /var/spool/.

For I/O activity:

iotop

Like top but for disk activity. Shows which processes are reading/writing the most. Install with apt install iotop if missing.

Bandwidth

Check current and monthly bandwidth from your iWebVault client area — under your VPS service, the usage tab shows month-to-date inbound/outbound. The server itself doesn’t track monthly totals natively without extra tools.

For live bandwidth:

# Install once
apt install vnstat -y

# Then check stats
vnstat -d        # daily
vnstat -m        # monthly
vnstat -h        # hourly

vnstat needs to run for a day or two before its stats are meaningful (it accumulates data over time, doesn’t backfill).

Setting up automated monitoring

Manual checks tell you what’s happening now. Automated monitoring tells you when things go wrong without you looking. Three levels of automation:

Free: UptimeRobot

UptimeRobot pings your sites every 5 minutes from external locations. You get an alert (email/SMS/Telegram) when a site goes down. Free tier covers 50 monitors. Set this up for every site you care about, including your panel URLs (cPanel/DirectAdmin/WHM).

Built-in: cPanel/DirectAdmin notifications

Both panels can email you about high resource usage, full disks, brute-force attacks, etc. Configure your notification email in the panel’s preferences. These cover server-internal events that external monitoring can’t see.

Self-hosted: Netdata or Prometheus

If you want real graphs and historical metrics:

bash <(curl -Ss https://my-netdata.io/kickstart.sh)

One-line Netdata install. Access at http://server.yourdomain.com:19999 — beautiful real-time graphs of every metric you’d want. Lock it down behind a firewall or auth before exposing publicly.

What triggers suspension

iWebVault suspends VPS services rarely, and almost never without warning. The triggers, in order of frequency:

• Network abuse from your IP. Compromised site sending spam, brute-force outbound, DDoS participation — any of these will get flagged by abuse desks at other providers. You’ll get a ticket explaining; if not resolved within hours, the service gets nullrouted (network blocked) until cleaned.
• Bandwidth wildly exceeding plan. 2-3× your monthly allowance triggers a review. Stay within plan, or upgrade before going over.
• CPU saturation across an entire physical host. Rare — only happens with massively misconfigured services (a malware-mining process consuming all cores). Resolved quickly once detected.
• Non-payment. Standard process — overdue invoice → reminders → service suspension. Pay the invoice and service resumes within minutes.
• Abuse-policy violation. Hosting content prohibited by our Acceptable Use Policy. Different process — investigation first.

For everything but billing, you’ll get a ticket before suspension. Don’t ignore tickets from us — that’s almost always how surprise suspensions happen.

Common resource issues and fixes

WordPress site eating CPU. Usually an unoptimized plugin, a runaway cron, or bots scraping aggressively. Install a caching plugin (LiteSpeed Cache for our LiteSpeed servers, or W3 Total Cache). Add Cloudflare’s free tier in front to filter bots before they reach your server.

MySQL using all RAM. Your innodb_buffer_pool_size is mis-sized. The rule of thumb: 50-70% of total RAM on a dedicated DB server, 25-40% on a shared server. Edit /etc/my.cnf, restart MySQL.

Disk filling overnight. Usually a log file growing unchecked. Find it: find / -type f -size +500M 2>/dev/null. Common culprits: /var/log/syslog, /var/log/messages, MySQL slow-query log. Implement log rotation.

Bandwidth maxing out. Either you’re being DDoS’d (check logs for repeated IPs), you’re hosting a viral video/download (use a CDN), or a misconfigured script is running in a tight loop. Identify with iftop for live connections.

Load average sky-high but everything looks idle. High I/O wait usually. iostat -x 1 or iotop identifies the process. Often a database with bad indexes doing full table scans.

What’s next

• Just installed your VPS? SSH first-time setup.
• Installing a panel: control panel install guide.
• Wondering if you need to upgrade? Plan selection guide.

Spend 30 minutes a week looking at your monitoring dashboards and you’ll catch problems before they become outages. The goal isn’t 0% resource usage — it’s predictable, understood resource usage.