If you manage a Linux server, you probably already know that something can go wrong at any time. What's less obvious is how much of that downtime is preventable with the right monitoring in place.
The Uptime Institute's 2025 Annual Outage Analysis found that 54% of organizations reported their most recent significant incident cost over $100,000, with 20% exceeding $1 million. A large share of that cost comes down to slow detection, with problems building for hours before anyone noticed.
On reliable VPS servers running Linux, you have everything you need to catch problems early. This guide walks through the key commands for monitoring server performance and uptime, what the output actually tells you, and how to recognize early when something needs attention.
What Should You Monitor on a Linux Server?
Linux server monitoring covers two separate concerns:
- Uptime monitoring checks whether your server is reachable at all
- Performance monitoring tracks what the server is doing while it's running
A server can be fully online and still be dangerously underpowered or one resource spike away from an outage, so both need attention.
The core metrics that give you meaningful coverage are CPU utilization and load average, memory usage and swap activity, disk space and I/O performance, network connections, and whether your application is actually responding to requests.
Linux Commands for Real-Time Performance Monitoring
The table below covers the core metrics, the commands that surface them, and the thresholds worth paying attention to. All of them come built into most Linux distributions.
| Metric | Command | What It Shows | When to Investigate |
|---|---|---|---|
| CPU & load | top or htop | Live CPU usage per process, load averages | Load average consistently above your CPU core count |
| Memory | free -h | Used, free, cached RAM and swap | Swap usage climbing steadily over time |
| Disk space | df -h | Filesystem usage per partition | Any partition above 85% full |
| Disk I/O | iostat -x 2 5 | Read/write latency and throughput | High await values alongside slow application response |
| Network | ss -tuln | Active connections, listening ports | Missing listeners or unexpected connection counts |
| Uptime | uptime | How long the server has been running, load averages over 1, 5, and 15 minutes | Load spikes that don't match expected traffic patterns |
Load average counts runnable processes alongside those blocked on disk I/O (not just CPU activity), which is why high load with normal CPU usage usually points to a storage constraint rather than a compute one. Run iostat to confirm before making any changes.
How to Check Server Uptime on Linux
The uptime command returns how long the server has been running, the number of active sessions, and load averages across three time windows (1, 5, and 15 minutes):
uptime
If the uptime value has reset unexpectedly, the server went down and came back at some point. To find out exactly when, pull the reboot history with:
last reboot
The last command reads /var/log/wtmp and returns a timestamped record of every restart. When you're investigating unexpected downtime on your VPS, start here.
Reading Memory Usage Without Getting Misled
Run free -h and you'll almost certainly see very little in the "free" column. Linux aggressively uses spare RAM as a disk cache, so low "free" memory on its own says nothing useful about whether your server is under pressure.
The column worth watching is available, which shows how much memory new processes can actually claim before the system starts swapping. If that number is consistently low, or if you see the si and so columns in vmstat 2 5 showing regular swap-in and swap-out activity, that's worth investigating. Application errors coinciding with low available memory values are another reliable signal.
Persistent swapping under normal load generally means the server's RAM allocation no longer fits the workload running on it.
Setting Up Basic Uptime Alerts
Manual checks only cover the moments you happen to be logged in. For anything production-grade, you need automated monitoring that watches in the background and alerts you when something crosses a threshold.
A simple cron job covers disk space without any extra tooling:
*/10 * * * * df -h / | awk 'NR==2 {if ($5+0 > 85) print "Disk alert: "$5" used"}' | mail -s "Disk Warning" [email protected]If you need retained history and dashboards, Prometheus with node_exporter and Grafana is the standard choice for Linux infrastructure. It takes more effort to configure, but gives you long-term trend data and flexible alerting across all your key metrics.
Worth adding alongside host-level tools is an external uptime service. Host-based agents can’t report their own outage, and if the server goes completely offline, nothing inside it fires an alert. External monitors check reachability from outside your network and catch failures that internal agents never see.
Final Thoughts
Baselining is probably the most underused practice in Linux server monitoring. Running top or free -h during an incident tells you what's happening now, but without knowing what normal looks like on your specific server under your typical workload, the numbers are hard to interpret. Spend ten minutes capturing output during a quiet period and a busy one. You'll have a reference point that makes every future investigation faster and more accurate.
