Monitor CPU, RAM, Disk and Network on a Linux VPS

What this guide helps you do

Use built-in Linux tools to answer the first question in almost every incident: what resource is actually under pressure? Before upgrading a VPS or tuning an application, identify the constrained resource. High load can come from CPU saturation, I/O wait, memory pressure or blocked processes. A full filesystem can break databases even while CPU looks idle. Monitoring several signals together prevents expensive guesses. This guide is written for production-minded administrators and site owners: make a backup before material changes, keep credentials private, and prefer the controls supplied by your own hosting provider when its environment differs from a generic example.

Before you begin

Record the domain, server or station you are changing and the current working state. If the task touches DNS, SSH, firewall rules, databases, stream credentials or application configuration, make sure you have a recovery path first. Screens and menu names can vary between cPanel, AzuraCast, VDO Panel and Linux releases, so follow the purpose of each step rather than forcing an old screenshot onto a newer version.

Step 1: Start with uptime/load and free -h. Compare load with available CPU cores and check whether swap is heavily used. A single snapshot is not enough; look for a pattern around the reported incident.

Start with uptime/load and free -h. Compare load with available CPU cores and check whether swap is heavily used. A single snapshot is not enough; look for a pattern around the reported incident.

Step 2: Use df -h and df -i. A filesystem can be out of inodes even when gigabytes remain free. Find the affected mount before deleting anything.

Use df -h and df -i. A filesystem can be out of inodes even when gigabytes remain free. Find the affected mount before deleting anything.

Step 3: Use top or htop to identify processes consuming CPU or memory. Do not kill a process solely because it appears first in the list; identify what service owns it and why it is busy.

Use top or htop to identify processes consuming CPU or memory. Do not kill a process solely because it appears first in the list; identify what service owns it and why it is busy.

Step 4: Use ss -tulpn to see listeners and tools such as ip -s link for interface counters. For sustained transfer diagnosis, use monitoring supplied by the VPS platform or install a supported metrics agent.

Use ss -tulpn to see listeners and tools such as ip -s link for interface counters. For sustained transfer diagnosis, use monitoring supplied by the VPS platform or install a supported metrics agent.

Step 5: Review application and system logs at the same timestamp. Resource spikes often correlate with crawlers, backups, scheduled jobs, database queries or deployment events.

Review application and system logs at the same timestamp. Resource spikes often correlate with crawlers, backups, scheduled jobs, database queries or deployment events.

Useful commands or examples

The following commands are examples for the context described in this guide. Read them before running them, substitute your real service names or hostnames, and keep a working administrative session open for network or SSH changes.

uptime
free -h
df -h
df -i
ps aux --sort=-%mem | head
ps aux --sort=-%cpu | head
ss -tulpn
ip -s link

Verification checklist

Record timestamps, load average, memory/swap, free disk, inode usage, top processes and relevant logs. Scale the VPS only when the evidence shows sustained capacity pressure rather than a one-off bad process or runaway job. Always test from the user side as well as the administrator side. A control panel saying “active” is useful evidence, but it is not the same as an external browser, player or SSH client proving that the full path works.

Troubleshooting method

When the result is not what you expected, avoid changing several unrelated settings at once. Identify the last known-good point, collect the exact error message and determine which layer is failing: DNS, network, authentication, service process, application configuration, web/stream delivery or browser/player. Check timestamps and logs around the failure. If you need to escalate to hosting support, include the affected hostname or station, the time of the test, what you expected, what happened instead and the checks you already completed. Do not include passwords, API keys or private stream keys in a public ticket or screenshot.

Keep the system maintainable

Document the final configuration after it works. Note the important URLs, service names, backup locations, renewal/expiry dependencies and any change that would surprise another administrator. Revisit the setup after major platform upgrades because defaults, supported runtimes and interface labels evolve. A reliable environment is not one that was configured once; it is one whose current state is understood, monitored and recoverable.

Where to go next

Use the related guides below to expand the setup rather than solving the same problem from scratch. If the platform has outgrown shared hosting or you need managed implementation, the service recommendation at the bottom of this guide links to the most relevant hosting, streaming, development or optimisation option on this site.