# How to Monitor VPS CPU RAM and Disk Usage - Link: https://offshorehosting.pk/how-to-monitor-vps-cpu-ram-and-disk-usage/ - Published: 2026-10-25T10:25:00+00:00 - Author: admin # How to Monitor VPS CPU, RAM and Disk Usage A VPS does not send you a warning when it is about to run out of memory or disk space. It simply slows down, starts failing requests, or stops responding — usually at the worst possible moment. Monitoring is how you see the problem coming while there is still time to fix it. This guide covers the essentials: the commands that show what is happening right now, how to read the numbers correctly, and how to set up ongoing monitoring and alerts so you are warned before a resource problem becomes downtime. ## Why Monitoring Matters Three scenarios make monitoring non-negotiable: * **Slow degradation.** A database that grows a little every week, a log file that never rotates, a memory leak in a long-running process — these creep up over months and then fail suddenly. Monitoring shows the trend line, so you can act on the trajectory instead of the crisis. * **Traffic changes.** A successful campaign or a viral post can double resource usage overnight. Without monitoring, the first sign is a site that stops loading. * **Security incidents.** Unusual CPU usage can be the first sign of a compromised server — a crypto miner, for example, shows up as sustained high CPU with no corresponding increase in legitimate traffic. Monitoring gives you a baseline, and anything that deviates from it deserves investigation. See [a beginner VPS security checklist](https://offshorehosting.pk/blog/a-beginner-vps-security-checklist). Monitoring is also how you size correctly. The usage data you collect today is the evidence you need when deciding whether to upgrade — see [how to size a VPS for your application](https://offshorehosting.pk/blog/how-to-size-a-vps-for-your-application). ## The Quick Commands: What Is Happening Right Now These commands are available on almost every Linux server and answer the immediate question: is the server under pressure? ### CPU and memory: `top`, `htop`, and `free` `top` shows a live, updating view of CPU and memory usage per process. `htop` is the same idea with a clearer interface — install it with `sudo apt install htop` on Debian/Ubuntu or `sudo dnf install htop` on RHEL-based systems. Sort by CPU or memory to find the process consuming the most. For memory specifically, `free -h` gives the overview: ```bash free -h # total used free shared buff/cache available # Mem: 3.8Gi 1.9Gi 412Mi 124Mi 1.5Gi 1.6Gi # Swap: 2.0Gi 0.0Ki 2.0Gi ``` Read the **available** column, not **free**. Linux uses spare memory for disk cache( the `buff/cache` column), so **free** is often low on a healthy server. **Available** is the memory that applications can actually use. If **available** is close to zero, the server is genuinely short of memory. Any sustained swap usage — the **used** column under Swap above zero — is a warning sign: the server is already borrowing from disk because RAM is exhausted, and performance will suffer. ### CPU load: `uptime` and load averages ```bash uptime # 20:14:03 up 42 days, 3:12, 1 user, load average: 0.85, 0.62, 0.41 ``` The three numbers are the load average over the last 1, 5 and 15 minutes — roughly, how many processes were waiting for CPU. Compare them with the number of CPU cores: on a 2-core server, a load average of 2.0 means the CPUs are fully busy; sustained load above the core count means processes are queuing. A load average that is rising across the three numbers (1-minute higher than 15-minute) means demand is increasing right now. ### Disk: `df` and `du` ```bash df -h # Filesystem Size Used Avail Use% Mounted on # /dev/vda1 49G 31G 16G 66% / ``` Watch the **Use%** column. A disk that reaches 100% causes immediate failures: databases cannot write, logs cannot rotate, uploads fail, and some services refuse to start. Set an alert well before that point (see below). To find what is using the space,` du` shows directory sizes: ```bash sudo du -sh /var/* /home/* 2>/dev/null | sort -h ``` Common culprits are unrotated logs in `/var/log`, old backups, and runaway cache directories. Never delete files blindly — confirm what a directory contains before removing it, and never delete a live database’s files while the database is running. ### Disk I/O: `iostat` and `iotop` If the CPU is idle but the server is slow, the disk may be the bottleneck. `iostat- x 1` (from the `sysstat` package) shows how busy each disk is and how long requests wait. High `%util` combined with high `await` means the disk cannot keep up — a common problem on older storage, and a reason to prefer NVMe SSDs. `iotop` shows which process is generating the I/O, the same way `top` shows CPU. ## Reading the Numbers: What “Normal” Looks Like Numbers without context are noise. Establish a baseline for your server during normal operation, then watch for deviation: | Metric | Healthy | Investigate | | CPU usage | Usually below 70% at peak | Sustained above 80–90% | | Load average | Below the core count | Sustained above the core count | | Memory available | Comfortable headroom | Consistently low; any sustained swap use | | Disk usage | Below 70% | Above 80%; urgent above 90% | | Disk I/O wait | Low, occasional spikes | Sustained high `%iowait` | | Network | Within the plan’s allowance | Approaching the monthly bandwidth limit | A single spike is not a problem — backups, updates and cron jobs all cause brief peaks. The pattern to worry about is a sustained change: CPU that used to idle at 20% now sits at 70%, or disk usage climbing steadily week after week. Trends are the signal; spikes are usually noise. ## Ongoing Monitoring: From Commands to Dashboards Manual commands are fine for a one-off check, but they do not help at 3 a.m. For ongoing monitoring, you need a tool that records history and sends alerts. **Lightweight, single-server options.** Netdata installs in minutes and gives a real-time web dashboard of CPU, memory, disk, network and per-process usage, with built-in alerts. It is a good first monitoring tool for a single VPS: low overhead, no configuration needed to start, and it shows trends as well as current values. **Full monitoring stacks.** Prometheus (metrics collection) with Grafana (dashboards and alerting) is the standard combination for larger setups and multiple servers. It takes more effort to set up, but it scales, keeps long-term history, and lets you build alerts such as “notify me if memory available falls below 15% for ten minutes”. If you manage several servers, this is the investment that pays off. **External uptime monitoring.** A tool on the server cannot tell you the server is down — because it goes down with it. An external service such as UptimeRobot checks your site from outside at regular intervals and alerts you when it stops responding. This is the simplest and most important monitoring of all: it answers the question “is the site up?” from the visitor’s point of view. Set it up on every production site, with alerts to an email address or messaging channel someone actually reads. ## Setting Up Alerts That Actually Help Alerts are only useful if they reach someone who acts on them. A few principles: * **Alert on thresholds with a delay.** Alerting on a single CPU spike creates noise; alerting when CPU stays above 80% for five minutes catches real problems. The same applies to memory and disk. * **Alert on disk space early.** Set the disk alert at 80% — not 95%. Filling a disk is a slow process until it is suddenly a crisis, and 80% gives you time to clean up or expand. * **Alert on services, not just resources.** Monitor that the web server, the database and the application are actually responding, not just that the machine is running. A server can have low CPU and plenty of memory while the database is down. * **Include the trend in the alert.** “Disk at 82% and growing 2% per week” tells you how much time you have; “disk at 82%” does not. * **Review and tune alerts regularly.** An alert that fires every day and is ignored is worse than no alert — it trains people to ignore all of them. If an alert is noisy, fix the threshold or fix the underlying problem. ## A Weekly Monitoring Routine Monitoring tools collect the data; a routine makes it useful. Once a week, spend ten minutes on: 1. The resource graphs: CPU, memory, disk — any sustained change from the baseline? 2. Disk usage: how much headroom, and what is growing? 3. The alert log: did anything fire, and was it handled? 4. The error logs: new errors in the web server or application logs? 5. Uptime: any downtime, and do you know why? That ten minutes is the cheapest insurance a VPS owner can buy. It catches the slow disk fill, the creeping memory leak and the degrading database weeks before they become an outage — and it gives you the data to size your next upgrade with confidence. ## Sources * htop — interactive process viewer: https://htop.dev/ * Netdata — real-time infrastructure monitoring: https://www.netdata.cloud/ * Prometheus — monitoring system: https://prometheus.io/ * Grafana — observability and dashboards: https://grafana.com/ * UptimeRobot — uptime monitoring: https://uptimerobot.com/ ## Sources * {‘title’: ‘htop — interactive process viewer (official site)’, ‘url’: ‘https:// htop.dev/’} * {‘title’: ‘Netdata — real-time infrastructure monitoring’, ‘url’: ‘https://www. netdata.cloud/’} * {‘title’: ‘Prometheus — monitoring system and time series database’, ‘url’: ‘ https://prometheus.io/’} * {‘title’: ‘Grafana — observability and dashboards’, ‘url’: ‘https://grafana.com/’} * {‘title’: ‘UptimeRobot — uptime monitoring’, ‘url’: ‘https://uptimerobot.com/’}