Linux Server Health Check: A Practical Checklist for Production Systems

OS Assistance · 20+ years of enterprise Linux experience

Prefer a senior engineer to inspect your fleet?

OS Assistance can review production health and prepare a prioritized 90-day remediation plan.Request a Health Check Review →

Long uptime can create a false sense of security. A Linux server may stay reachable while disk space shrinks, memory pressure builds, TCP listener drops increase, patches remain pending, or backups go untested. This quiet buildup is silent degradation: a system looks available even as its resilience erodes.

A useful Linux server health check combines a point-in-time inspection with recent logs, monitoring trends, and recovery evidence. This checklist reflects more than 20 years of enterprise Linux systems administration and architecture experience. It uses mostly read-only commands to review the operating system, storage, memory, CPU, network, access controls, updates, certificates, and backups. It applies to common systemd-based distributions, including RHEL-compatible systems, Ubuntu, and Debian; some commands may need to be adapted for your distribution or cloud platform.

Before a Linux server health check: inspect first, change later

Run checks only on systems you are authorized to administer. Record the server name, time, operating-system version, and command results. Avoid cleanup, package installation, service restarts, kernel tuning, and filesystem changes during the inspection. Redact hostnames, IP addresses, usernames, and other sensitive data before sharing a report.

If the review leads to a change, use the organization’s change process and verify the recovery plan first. A VM snapshot can help with rollback, but it is not a substitute for an independent, tested backup.

The Linux Server Health Check Checklist

Review the following areas in order, and compare each finding with the server’s normal baseline rather than relying on one generic threshold.

1. Record the server baseline

Start with the host identity, operating-system kernel, uptime, and time synchronization:

hostnamectl
uname -r
uptime
timedatectl status

hostnamectl and timedatectl are available on most systemd-based Linux distributions. If a command is unavailable, use the equivalent tools for that operating system. Confirm the host is the intended production or non-production system before interpreting results.

2. Check filesystem space, inodes, and storage latency

df -hT
df -ih
iostat -xz 1 5

df -hT reports used space and filesystem types. df -ih reports inode use; a filesystem can run out of inodes even when it still has free bytes. iostat is supplied by the sysstat package on many distributions. In its repeated output, focus on interval samples after the first report, then compare latency and queue behavior with the application’s normal baseline.

Treat a percentage such as 80% full as a warning threshold only if it fits the server’s growth rate and recovery needs. A fast-growing log filesystem may need attention earlier; a stable data volume may have a different threshold. Also check for deleted files that are still held open by a process:

sudo lsof +L1

High I/O utilization by itself does not identify the cause. Review latency, queue depth, throughput, and application response time together. Cloud storage has provider- and volume-specific performance limits. For example, AWS gp2 and gp3 volumes behave differently: eligible gp2 volumes use burst credits, while gp3 performance is provisioned separately. See the Amazon EBS General Purpose SSD documentation and compare it with the relevant cloud monitoring metrics.

3. Review memory pressure and OOM events

free -h
vmstat 1 5
ps -eo pid,user,rss,comm --sort=-rss | head -n 6
sudo journalctl -k --since "24 hours ago" --no-pager | grep -iE 'out of memory|oom-killer|killed process'

In free -h, use the available value to understand how much memory can be allocated without relying on swap. In vmstat, repeated non-zero si or so values indicate swap-in or swap-out activity during those samples; compare them with response time and disk activity. The process list sorts by resident memory (RSS), shown in KiB.

An OOM message is evidence that the kernel killed a process under memory pressure. Look at the timestamp, affected service, and surrounding logs before deciding whether the cause was a leak, an undersized host, a workload spike, or a limit imposed by a container or service manager.

4. Compare CPU load with runnable and blocked work

nproc
uptime
vmstat 1 5
ps -eo stat,pid,user,comm | awk '$1 ~ /^D/'
systemctl --failed

Load average is not a CPU percentage. Linux load includes runnable work and tasks in uninterruptible sleep, often waiting on I/O. Compare it with the number of CPUs, vmstat‘s CPU and I/O-wait columns, and the host’s normal pattern. Processes in D state deserve investigation, especially when they persist; check storage, NFS, and other I/O paths before changing anything.

systemctl --failed lists failed systemd units. Follow up on important services with their unit status and recent logs, for example:

sudo systemctl status nginx
sudo journalctl -u nginx --since "24 hours ago" --no-pager

Replace nginx with a critical service on the host. A failed unit can be expected or unrelated, so record its impact instead of treating every failure as a production incident.

5. Inspect network sockets, listener counters, and DNS

ss -s
ss -ltn
nstat -az | grep -E 'TcpExtListenOverflows|TcpExtListenDrops'
time getent ahosts example.com

ss summarizes sockets and listening TCP ports. nstat is available on many systems with iproute2; its listener counters are cumulative, so a non-zero value alone does not prove a current outage. Take two readings over a known interval and check whether the counters increase while users experience connection failures. Correlate that evidence with the application server’s accept queue and logs before considering backlog changes.

The DNS example measures the configured resolver path for example.com. Substitute a hostname used by the application. A slow or failed lookup should be compared across repeated tests and checked against the configured resolver and application logs.

6. Review SSH access, privilege, and security updates

Check the effective SSH daemon defaults and validate sudoers syntax:

sudo sshd -T | grep -Ei 'permitrootlogin|passwordauthentication|pubkeyauthentication'
sudo visudo -c

Review SSH Match blocks and included configuration files as well; the effective settings can vary by user, source address, or connection context. Organizations commonly use named administrator accounts, key-based access, and audited sudo rather than routine direct root login. Apply the access policy required by your environment and preserve a tested recovery path before tightening authentication.

Check pending updates with the package tools used by the operating system:

# RHEL, Rocky Linux, or AlmaLinux
sudo dnf updateinfo list --security

# Debian or Ubuntu: this lists all upgradable packages, not only security updates
apt list --upgradable

Package metadata can be stale, and the Debian/Ubuntu command does not identify security updates by itself. Use the distribution’s security advisories and approved update workflow to determine exposure. Do not install updates or reboot a production server as part of a read-only health check.

7. Verify backups and recovery readiness

Check the backup product’s job history and the scheduler that runs it. On systems using systemd timers, this command can help find scheduled jobs:

systemctl list-timers --all

Confirm the latest backup completed successfully, that the expected off-host or cloud copy exists, and that retention is working. Then review the most recent restore test: what was restored, when it was tested, how long recovery took, and whether application owners verified the result.

A successful backup job is not proof that an application can be recovered. Test representative files, databases, and configuration using a documented restore procedure. Keep recovery credentials and instructions available to the people who may need them during an outage.

8. Check the certificate served to users

For a public HTTPS endpoint, inspect the certificate dates with:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -dates

Replace example.com with the actual hostname. This checks the certificate presented by that endpoint; it does not verify the renewal job or prove that the Linux host serves TLS directly. If a CDN, reverse proxy, or load balancer terminates TLS, check the certificate and renewal process there as well.

Turn Linux server health check findings into an actionable report

For each finding, record the evidence and impact, then assign an owner and a review date. A useful report includes:

Finding	Evidence to record	Next step
Disk growth threatens service availability	Mount, current use, growth trend, and expected time to capacity	Identify the source and plan cleanup or expansion through change control
Memory pressure or OOM kill	Affected process, event time, swap activity, and workload context	Determine whether to tune, correct a leak, or add capacity
Listener drops during user impact	Counter change over time, service logs, and connection symptoms	Review application accept behavior and network path before tuning queues
Backup or restore gap	Last successful job, off-site copy, retention, and restore-test date	Schedule and document a restore test
Security update exposure	Affected package, vendor advisory, exposure, and maintenance window	Prioritize and schedule an approved update

Prioritize findings by service impact, likelihood, and time available to respond. Separate urgent risks from planned maintenance and longer-term improvements. The report should help an application owner decide what to fix, who will do it, and when to verify the result.

How often should you run a Linux server health check?

Use monitoring and alerting continuously for important production systems. Run a structured health review during onboarding, after significant changes, and on a regular schedule that matches the workload, risk, and recovery requirements. A health check complements monitoring: it brings system state, security posture, backup evidence, and operational context together for review.

Get help with a Linux server review

If you need an independent review or ongoing support, request a Linux health check or quote or contact OS Assistance.