How to monitor your VPS with a few basic command line tools

When a server feels slow, or something stops working, you need to answer a few questions quickly: is it the CPU, the memory, the disk or the network? What is using it? Linux ships with the tools to answer all of them. You do not need an expensive monitoring platform to find most problems, just a handful of commands and the habit of knowing what normal looks like.

Start with the overview: htop

top is installed everywhere, and htop is a friendlier version:

sudo apt install htop
htop

It shows each CPU core as a bar, memory and swap use, and a list of processes sorted by usage. Press F6 to change the sort column, and q to quit. Things to look for:

  • A single process using most of the CPU is the obvious suspect.
  • Memory almost full with swap in use means the server is short of memory. See How to add swap space to your VPS.
  • Many processes in state D often point to a disk problem.

Load average

At the top of htop, and from the uptime command, three numbers show the load average over the last 1, 5 and 15 minutes. Roughly, it is the number of processes wanting to run. Compare it with your number of CPU cores:

  • A load around or below the core count is healthy.
  • A load well above the core count means work is queueing.

A rising 1 minute figure with a calm 15 minute figure is a recent spike. All three high means a lasting problem.

Memory: free

free -h

Look at the available column, not "free". Linux deliberately uses spare memory for caching files, so "free" often looks small on a healthy system. Available is what programs could actually use. If available is near zero and swap is growing, you are out of memory. What the CPU, memory and disk numbers on your server mean covers the same ideas for hosted game servers.

Disk: df and du

df -h

Shows each disk and how full it is. Anything above about 90 percent deserves attention, because a full disk breaks databases, logs and updates. To find what is taking the space:

sudo du -h --max-depth=1 /var | sort -h

Run it on /var, /home or wherever the space is going, and go deeper into the biggest folder. Common culprits are logs, backups and Docker data. See Fixing "No space left on device".

What is listening on the network

sudo ss -tulpn

This lists every program listening on a port, with its process name. Check it against what you expect. An unexpected listener, especially one open to all addresses (0.0.0.0), is worth investigating. Pair it with your firewall rules, from Set up a firewall on your VPS with UFW, to be sure that only the right ports are reachable.

Logs: journalctl

sudo journalctl -u nginx --since "1 hour ago"
sudo journalctl -u myapp -f
sudo journalctl -p err -b

The first shows a service's recent logs, the second follows live output and the third shows every error since boot. -u selects a service. Read from the first error, as described in How to read your server logs.

Failed services

systemctl --failed

Lists services that have crashed or failed to start. It is a quick check after a reboot or an update.

Disk and network activity

Install the sysstat package for iostat, and nload or iftop for traffic:

sudo apt install sysstat nload
iostat -x 2
nload

iostat shows how busy the disk is. High wait times mean the disk is the bottleneck, which slows everything. nload shows live incoming and outgoing bandwidth.

Know your normal

The most valuable thing you can do is look at these numbers when everything is fine. A server using 60 percent memory and a load of 0.3 is your baseline. When something is wrong, the difference is what you notice. Write the figures down, or take a note when you set up the server.

Simple alerting

You do not need a big system. Three cheap ideas:

  1. An outside uptime check. Free services poll your website every few minutes and message you if it stops responding.
  2. A script run by cron that checks the disk and sends you a message when it passes a limit. See How to schedule tasks with cron.
  3. A service dashboard, such as Netdata, if you want graphs and alerts without building anything. It is free, and uses some memory itself, so install it knowingly.

A short routine

  • Weekly: look at df -h, free -h and systemctl --failed.
  • Monthly: review what is listening, and which updates are waiting.
  • After any change: watch the logs for a few minutes.

If you spot something odd that you cannot explain, ask for help with the exact output. How to write a good support request shows what to include.

Still stuck? Open a ticket on Discord - run /ticket in any channel, pick a department, and include your Server ID or Invoice ID so we can jump straight in.