Published: 01.10.2026
Monitoring tells you what your server is doing before a visitor reports a problem. The essentials are CPU, memory, disk and network, and the same few numbers answer most questions about a slow site or a stopped service. Every VPS in our client area includes graphs for CPU, disk and network use. This article explains how to read them, which commands help on the server and how to set simple alerts.
The four numbers to watch
- CPU: how busy the processor is. Short peaks are normal, while long periods near full use mean that work is queuing.
- Memory: how much RAM is in use and whether the system has started to use swap space. Heavy swapping shows up as a general slowdown.
- Disk: how full each file system is, and how quickly reads and writes complete.
- Network: how much data flows in and out, and whether a sudden change comes from a backup, a download or an attack.
Reading the graphs in the client area
Graphs show trends over time, and that is their strength. Look at the same period over several days, and compare weekdays with weekends. A gradual climb in disk use means you need cleanup or more space soon. A sharp spike in network use after a deployment may point to a new download job or a traffic surge. Mark changes in your own notes, so that a strange graph can be explained later.
Commands on the server
When you need the current picture, a few standard commands answer most questions:
- Run free with the human-readable option to see memory and swap usage.
- Run df with the human-readable option to see how full each file system is.
- Run uptime to see the load average over the last one, five and fifteen minutes. A load that stays above the number of cores means work is waiting for the processor.
- Run top, or htop if it is installed, to see which processes use the most CPU and memory. Press q to leave top.
- Run journalctl with the priority option set to err and the current boot option, to list the errors from this boot.
Setting simple alerts
Alerts make sure you hear about a problem before your visitors do. Start with the few thresholds that matter: disk above a chosen percentage, memory close to its limit for a long time, and a website that stops responding. Use the alerting that your tools provide. If the client area does not alert you on a metric you need, a small script run by cron can check disk usage and write a warning to a log or send you a message. Keep alerts few and meaningful, because too many alerts are ignored.
Check the outside view
Internal numbers do not show what visitors see. An external check that requests your home page from outside the server, and reports when it fails or responds slowly, complements the graphs. You can run such a check with a scheduled request from another machine, or use a monitoring service of your choice.
Logs and changes
Look at the logs of your web server and database for errors on a regular basis. A new type of error after a change is often the first sign of a problem. Record the date and a short note for each update, so that you can connect changes to what the graphs show. A plain text file in your administration folder is enough to start.
Frequently asked questions
How often should I check the graphs? Once a week is enough for a stable site. Check daily after a launch or a major change.
What is normal CPU usage? There is no single normal value. What matters is how usage changes over time and whether the site responds well at busy hours.
Do I need a special monitoring tool? Not at the start. The client area graphs and a few commands cover the basics. Add dedicated tools when you need alerts for more services.
