Linux Server Health Check Checklist: 15 Commands to Run First

A Linux server can look perfectly normal from the outside while something is already going wrong underneath: memory pressure, a full filesystem, a failed service, excessive CPU usage, disk I/O problems, or hundreds of unexpected network connections.

When a server becomes slow, unstable, or unreachable, the hardest part is often deciding where to start.

This Linux server health check checklist gives you 15 commands to run first. Together, they provide a fast overview of system uptime, CPU load, memory, disks, processes, services, logs, and network activity.

Linux Server Health Check: Quick Checklist

If you need a fast diagnostic sequence, run these commands in roughly this order:

uptime
hostnamectl
free -h
df -h
df -i
lsblk
top
ps aux --sort=-%cpu | head
ps aux --sort=-%mem | head
systemctl --failed
journalctl -p err -b
dmesg -T | tail -50
ss -tulpn
ip addr
ip route

You do not always need to investigate every command in detail. The goal is to quickly identify which subsystem deserves closer attention.

1. Check Server Uptime and Load with uptime

uptime

The uptime command is one of the fastest ways to get an initial picture of a Linux server.

Example:

14:21:37 up 18 days,  6:42,  2 users,  load average: 0.42, 0.51, 0.48

It shows:

• current system time;
• how long the server has been running;
• number of logged-in users;
• load average for the last 1, 5, and 15 minutes.

What to look for

Pay particular attention to the three load average values.

A load average of:

0.42, 0.51, 0.48

is generally not concerning on a multi-core server.

However, values such as:

12.40, 10.82, 8.91

may indicate that processes are competing for CPU time or waiting for resources such as disk I/O.

Load average should always be interpreted relative to the number of available CPU cores.

Check that with:

nproc

For example, a load of 4 on a 16-core server is very different from a load of 4 on a 2-core server.

2. Identify the Server with hostnamectl

hostnamectl

Before troubleshooting, confirm exactly which machine and operating system you are working with.

hostnamectl typically displays information such as:

• hostname;
• operating system;
• kernel version;
• system architecture;
• virtualization environment.

Example:

 Static hostname: web01
       Icon name: computer-vm
         Chassis: vm
      Machine ID: ...
         Boot ID: ...
  Virtualization: kvm
Operating System: Ubuntu 24.04 LTS
          Kernel: Linux 6.8.0-xx-generic
    Architecture: x86-64

Why this matters

Administrators frequently manage multiple production, staging, and development servers. Running a repair command on the wrong machine can turn a small problem into a much larger one.

Always verify the hostname before making changes.

3. Check Memory Usage with free -h

free -h

The free command gives you a quick overview of physical memory and swap usage.

Example:

               total        used        free      shared  buff/cache   available
Mem:            15Gi       5.1Gi       1.2Gi       210Mi       9.0Gi       9.8Gi
Swap:          2.0Gi       128Mi       1.9Gi

Do not focus only on the “free” column

Linux intentionally uses unused memory for filesystem cache. A server can therefore have very little completely unused RAM while still having plenty of memory available for applications.

The more useful value is usually:

available

If available memory is extremely low and swap usage is continuously increasing, the server may be experiencing memory pressure.

Warning signs

• very little available RAM;
• rapidly increasing swap usage;
• applications being killed unexpectedly;
• high disk activity caused by swapping;
• Out Of Memory messages in system logs.

4. Check Disk Space with df -h

df -h

A full filesystem is one of the most common causes of Linux server problems.

Example:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        80G   51G   25G  68% /
/dev/vdb1       200G  184G   16G  93% /data

What to look for

Pay attention to filesystems approaching 100% usage.

Once a filesystem becomes completely full, applications may be unable to:

• write logs;
• create temporary files;
• update databases;
• save uploaded files;
• install packages;
• restart normally.

A filesystem above roughly 80–90% usage deserves investigation, although the appropriate threshold depends on the size and purpose of the filesystem.

5. Check Inode Usage with df -i

df -i

A filesystem can report plenty of free disk space and still refuse to create new files.

Why?

Because Linux filesystems also have a finite number of inodes.

An inode stores filesystem metadata associated with a file or directory.

Example:

Filesystem      Inodes   IUsed    IFree IUse% Mounted on
/dev/vda1      5242880  342119  4900761    7% /

A common inode problem

Servers that generate millions of tiny files can exhaust their inode supply even when significant storage capacity remains available.

This can happen with:

• cache directories;
• mail queues;
• temporary files;
• PHP sessions;
• application-generated files;
• poorly configured logging systems.

If IUse% reaches 100%, new files cannot be created on that filesystem.

6. Inspect Disks and Partitions with lsblk

lsblk

lsblk displays block devices attached to the server.

Example:

NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
vda    252:0    0   80G  0 disk
├─vda1 252:1    0   79G  0 part /
└─vda2 252:2    0    1G  0 part /boot
vdb    252:16   0  200G  0 disk
└─vdb1 252:17   0  200G  0 part /data

This helps you understand:

• which disks are available;
• disk sizes;
• partition layout;
• mount points;
• LVM relationships;
• additional attached storage.

A useful expanded version is:

lsblk -f

It also displays filesystem types, UUIDs, and mount information.

7. Find CPU-Hungry Processes with top

top

The top command provides a real-time view of Linux system activity.

It displays information including:

• system load;
• CPU utilization;
• memory usage;
• swap usage;
• running processes;
• process CPU consumption;
• process memory consumption.

Useful indicators

Look at the CPU line near the top of the screen.

You may see values such as:

%Cpu(s): 12.3 us,  3.1 sy,  0.0 ni, 83.8 id,  0.4 wa

Important fields include:

• us — CPU time used by user processes;
• sy — CPU time used by the kernel;
• id — idle CPU;
• wa — CPU time waiting for I/O.

A high wa value can indicate disk or storage performance problems rather than a pure CPU shortage.

Press q to exit top.

8. List the Highest CPU Consumers with ps

ps aux --sort=-%cpu | head

This command gives you a quick static list of the processes currently using the most CPU.

Example:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
mysql     1921 42.1 18.2 ... 
www-data  8452 16.7  2.1 ...
www-data  8460 14.4  2.0 ...

This can immediately point you toward:

• a runaway application;
• a database query problem;
• too many web server workers;
• a backup or compression job;
• a compromised process;
• a scheduled task consuming unexpected CPU resources.

If one process constantly consumes a large amount of CPU, investigate that application before simply terminating it.

9. Find the Highest Memory Consumers with ps

ps aux --sort=-%mem | head

This variation sorts processes by memory consumption instead of CPU usage.

It is especially useful when:

• available RAM is low;
• swap usage is increasing;
• applications are being killed;
• the server becomes progressively slower over time.

Look at the %MEM and RSS values.

Remember that diagnosing memory consumption can be more complicated than simply adding process percentages because applications may use shared memory and filesystem cache.

10. Find Failed Services with systemctl –failed

systemctl --failed

On Linux distributions using systemd, this command displays units that have entered a failed state.

Example:

UNIT                LOAD   ACTIVE SUB    DESCRIPTION
nginx.service       loaded failed failed A high performance web server
backup.service      loaded failed failed Daily backup service

If a service has failed, inspect it with:

systemctl status nginx

Replace nginx with the service you need to investigate.

Do not immediately restart everything

A failed service is a symptom. Before restarting it, try to understand why it failed.

Possible causes include:

• invalid configuration;
• missing files;
• permissions;
• a full filesystem;
• port conflicts;
• memory exhaustion;
• dependency failures;
• application crashes.

11. Check Current Boot Errors with journalctl

journalctl -p err -b

This command asks the systemd journal to display error-level messages from the current boot.

The options mean:

• -p err — show messages with error priority;
• -b — limit results to the current boot.

This is one of the most useful commands when you know something is wrong but do not yet know which service caused the problem.

Check a specific service

For example:

journalctl -u nginx

Or show recent messages:

journalctl -u nginx -n 100

Follow new log messages in real time:

journalctl -u nginx -f

12. Check Kernel Messages with dmesg

dmesg -T | tail -50

dmesg shows messages from the Linux kernel ring buffer.

The -T option displays human-readable timestamps, while tail -50 limits the output to the most recent 50 lines.

Kernel messages can reveal problems involving:

• disks;
• filesystems;
• network interfaces;
• drivers;
• memory;
• hardware;
• virtual devices;
• Out Of Memory events.

Search for common problems

dmesg -T | grep -i error

You can also look for Out Of Memory events:

dmesg -T | grep -i -E 'oom|out of memory|killed process'

If the kernel’s OOM killer has terminated an application, these messages can explain why a service suddenly disappeared or restarted.

13. Check Listening Ports and Connections with ss

ss -tulpn

The ss command is an essential Linux networking diagnostic tool.

The options above request:

• -t — TCP sockets;
• -u — UDP sockets;
• -l — listening sockets;
• -p — associated processes;
• -n — numeric addresses and ports.

Example:

Netid State  Local Address:Port   Process
tcp   LISTEN 0.0.0.0:22          users:(("sshd",pid=821,fd=3))
tcp   LISTEN 0.0.0.0:80          users:(("nginx",pid=1421,fd=6))
tcp   LISTEN 0.0.0.0:443         users:(("nginx",pid=1421,fd=7))
tcp   LISTEN 127.0.0.1:3306      users:(("mysqld",pid=1612,fd=21))

Why this matters

If an application is supposed to accept network connections but clients cannot reach it, check whether the expected port is actually listening.

For example, check port 443:

ss -tulpn | grep ':443'

You can also inspect all TCP connections:

ss -tan

An unexpectedly large number of connections can indicate an overloaded application, a connection leak, aggressive crawlers, or malicious traffic.

14. Check Network Interfaces with ip addr

ip addr

This command displays Linux network interfaces and their assigned IP addresses.

A shorter form is:

ip a

Use it to verify:

• which network interfaces exist;
• whether an interface is up;
• IPv4 addresses;
• IPv6 addresses;
• loopback configuration.

For example:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
    inet 192.168.1.20/24 brd 192.168.1.255 scope global eth0

If the expected IP address is missing, investigating DNS or the application itself may be premature. The problem may be at the network configuration level.

15. Check the Routing Table with ip route

ip route

A server can have the correct IP address and still be unable to communicate with other networks if its routing configuration is incorrect.

Example:

default via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.20

The most important entry on many servers is the default route:

default via 192.168.1.1 dev eth0

If the default gateway is missing or incorrect, connections to external networks may fail.

What Should You Check First on a Slow Linux Server?

If the main complaint is simply “the server is slow”, start with this shorter sequence:

uptime
free -h
df -h
top
ps aux --sort=-%cpu | head
ps aux --sort=-%mem | head
systemctl --failed
journalctl -p err -b

This quickly answers several important questions:

1. Is system load unusually high?
2. Is the server running out of memory?
3. Is a filesystem full?
4. Is one process consuming most of the CPU?
5. Is one process consuming most of the RAM?
6. Has a systemd service failed?
7. Are the logs reporting an obvious error?

What Should You Check First When a Website Is Down?

For a Linux web server, a useful first-pass sequence is:

uptime
df -h
free -h
systemctl --failed
systemctl status nginx
ss -tulpn
journalctl -u nginx -n 100
ip addr
ip route

If you use Apache instead of Nginx, substitute the appropriate service name, for example:

systemctl status apache2

On some Red Hat-based systems:

systemctl status httpd

What Should You Check After a Server Reboot?

After rebooting a Linux server, verify at least:

uptime
systemctl --failed
journalctl -p err -b
df -h
free -h
ss -tulpn
ip addr
ip route

This confirms that the server booted successfully, expected services started, storage is mounted, networking is configured, and important application ports are listening.

Bonus Commands for Deeper Troubleshooting

The first 15 commands are designed for rapid health checks. If they reveal a problem, these additional commands can help you investigate further.

Check CPU information

lscpu

Check available CPU cores

nproc

Check filesystem mounts

findmnt

Check recently logged-in users

last

Check currently logged-in users

w

Check failed SSH login attempts

On systems using the systemd journal:

journalctl -u ssh

or:

journalctl -u sshd

Check DNS resolution

getent hosts example.com

Test network connectivity

ping -c 4 1.1.1.1

Test an HTTP endpoint

curl -I https://example.com

A Practical Linux Server Troubleshooting Order

Randomly running commands is rarely an efficient troubleshooting strategy. A better approach is to move from the general state of the system toward the specific service that is failing.

A useful order is:

1. Confirm the server. Check hostname, OS, and uptime.
2. Check system pressure. Look at load, CPU, RAM, and swap.
3. Check storage. Verify disk space, inodes, disks, and mounts.
4. Check processes. Identify abnormal CPU or memory consumers.
5. Check services. Find failed systemd units.
6. Check logs. Read service, system, and kernel errors.
7. Check networking. Verify interfaces, routes, listening ports, and connections.
8. Investigate the affected application. Only after the underlying server appears healthy.

This approach prevents you from spending 30 minutes debugging an application configuration when the real problem is simply a full disk or exhausted memory.

Linux Server Health Check Cheat Sheet

Final Thoughts

A good Linux server health check does not begin by changing configuration files or restarting random services. It begins by collecting information.

The 15 commands in this checklist provide a fast overview of the most important parts of a Linux system:

• CPU and load;
• RAM and swap;
• disk space and inodes;
• processes;
• systemd services;
• system and kernel logs;
• network interfaces;
• routes;
• listening ports.

For many incidents, these commands are enough to identify the subsystem causing the problem within the first few minutes of troubleshooting.

Keep the checklist available on every server you manage. When something breaks, start with evidence, narrow down the problem, and only then make changes.