When a Linux server stops responding, the temptation is usually to connect via SSH and start executing commands. top, free, df, systemctl, journalctl. All are useful, but they shouldn’t always be the first step. Before diagnosing CPU, memory, or disk issues, it’s better to ask a more fundamental question: Is the server truly down or just unreachable via a specific route?
That’s why, in a real incident, the first command isn’t usually something inside the server. It’s often something as simple as:
ping -c 4 <server_ip/>Or, if you want a slightly more useful tool to see intermediate hops:
mtr <server_ip/>The reason is straightforward. If there’s no connectivity, everything else changes. The operating system might be running, but there could be a network problem, firewall, routing issue, switch, VPN, load balancer, cloud provider, or security rule. If you start directly with SSH and it doesn’t respond, you might jump to the wrong conclusion: “the server is dead.” Sometimes it’s not. It’s just isolated.
Good diagnosis in systems begins with separating symptoms. It’s not the same if a web page doesn’t load, port 22 doesn’t respond, ICMP isn’t received, the server is frozen, the kernel is alive but no useful processes are running, or the disk is at 100% and logs can’t be written.
First, determine if there’s a path to the machine
The first minute of an incident should be used to confirm scope. Is one server failing or multiple? Is one service failing or the entire machine? Is it failing from one location or from any network? Are users affected or just specific monitoring?
A reasonable flow would start with connectivity checks:
ping -c 4 <ip/>Next, verify the route:
mtr <ip/>And if the server responds to ping, test the affected service:
curl -I https://domain.com
nc -vz <ip> 22
nc -vz <ip> 443This helps identify if the problem is on the network, port, service, or an intermediate layer. If ping responds but SSH doesn’t, the server isn’t necessarily dead. There could be issues with sshd, firewall rules, process saturation, connection limits, or such high load that the session cannot be established.
If nothing responds, the next step isn’t to blindly restart. Instead, check via an alternative console: KVM, iLO, iDRAC, IPMI, hypervisor console, cloud provider console, or serial access if available. Restarting might recover service but could also erase useful evidence and turn a diagnosable incident into a rootless anecdote.
| Initial symptom | First assessment | Reasonable next step |
|---|---|---|
| No ping response | Possible network, firewall, total outage, or ICMP blocked | Check route, console, provider, switch, or security |
| Ping responds, no SSH | System alive but access blocked or overloaded | Test port 22, alternative console, logs |
| SSH slow response | High load, I/O wait, DNS, PAM, disk, or processes | Access and run quick diagnostics |
| Web down, SSH responds | Service or application issue, not entire machine | Check systemctl, logs, ports, and resources |
| Everything slow to respond | CPU, RAM, disk, network, or external dependency | Measure before acting |
If SSH responds, the first useful command is uptime
Once inside the server, the first command that offers a quick snapshot is:
uptimeIt doesn’t fix anything but provides orientation. Shows how long the machine has been up, how many users are connected, and importantly, the load average. If the load average is high, that’s a clue. For example, a machine with 4 vCPUs showing loads of 80, 120, or 300 might be alive but practically unusable.
Then, it makes sense to look at processes:
top -b -n 1 | head -20Or a more direct CPU view:
ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%cpu | headAnd for memory:
free -h
ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%mem | headAt this point, it’s easier to tell if the problem points to CPU, RAM, swap, looping processes, memory leaks, or too many blocked tasks.
A crucial detail: if many processes are in D state, the issue might be with disk or storage, not CPU. A server may appear frozen waiting for I/O operations to complete. Killing processes blindly here can worsen the scenario.
Disks, inodes, and logs: three classic culprits still bringing servers down
Many Linux incidents still stem from unglamorous causes: a full disk, uncontrolled log directory, poorly scheduled backups, an application writing millions of tiny files, a /var partition at 100%, or a volume running out of inodes despite having free space in GB.
Therefore, the following commands should always be handy:
df -h
df -i
du -xhd 1 / 2>/dev/null | sort -hr | headdf -h shows disk space; df -i shows inodes. The latter is often overlooked. If inodes are exhausted, new files can’t be created even if space remains.
Recent logs are also crucial:
journalctl -xe --no-pager | tail -50
journalctl -p err --since "1 hour ago"
dmesg -T | tail -100These can reveal kernel errors, disk failures, OOM Killer activity, services restarting in a loop, network issues, or I/O messages. Before rebooting, it’s wise to review these logs—rebooting might erase the ephemeral context explaining the failure.
Mitigating is not the same as diagnosing
During an incident, two objectives compete: restoring service and understanding the cause. The balance depends on impact. For severe outages, mitigation must be quick but not at the expense of destroying all evidence.
Some common actions:
| Symptom | Probable cause | Mitigation action |
|---|---|---|
| CPU at 100% | Loop process or abnormal load | Identify PID and stop carefully |
| Memory exhausted | Memory leak or excessive processes | Restart affected service, not necessarily the entire server |
| Disk full | Logs, temp files, backups, or dumps | Clean temp files, truncate logs carefully |
| Inodes full | Many small files | Locate directories and delete/move with discretion |
| Service down | Application failure | systemctl status and controlled restart |
| Many connections | Peak, abuse, or leak | Check limits, application, firewall, load balancer |
A command like this might be necessary:
kill -9 <pid/>But it should be a conscious decision, not a reflex. kill -9 prevents processes from shutting down cleanly. Sometimes it’s unavoidable; other times, restarting a service or canceling a job queue suffices.
The same applies to rebooting the server:
systemctl reboot --forceThis should be a last resort. If the system is completely frozen and unrecoverable, console access or SysRq commands may be necessary—only if you know what you’re doing. Quick recovery should not lead to data loss.
The incident doesn’t end when the service is back
One of the most costly operational errors is to close the incident once the web responds again. That’s the end of the outage, not the end of the analysis. It’s essential to document what happened, how long it lasted, its impact, what was done, what worked, and what should be changed to prevent future recurrence.
A good post-incident review should answer:
| Question | Why it matters |
|---|---|
| What exactly failed? | Prevents staying at symptoms |
| When did it start and end? | Enables measuring actual impact |
| Which users or services were affected? | Helps prioritize prevention |
| What signals warned? | Improves monitoring |
| What action recovered the service? | Documents effective response |
| What preventive measure is missing? | Turns incident into a lesson |
The golden rule is simple: don’t guess. Observe, measure, and understand before acting. A good system administrator is not the one who executes the most commands, but the one who knows the right order and when to stop before causing more damage.
If you had to choose a quick answer to the initial question, it would be this: first, check connectivity with ping or mtr; if SSH responds, run uptime. The first separates network from system. The second provides a quick read on load and overall status. From there, the diagnosis is no longer blind.
Frequently Asked Questions
What is the first command to run if a server is unresponsive?
From outside, use ping -c 4 <ip/> or mtr <ip/> to check connectivity. If SSH responds, inside the server, the first useful command is usually uptime.
Why not start directly with top?
Because you might not even have real access to the server yet. First, determine if the problem is network, access, port, service, or the whole system.
Which command helps detect disk full?df -h for space, df -i for inodes. Both are important since a system can run out of inodes even if space remains.
What logs should be checked in the first minutes?journalctl -xe --no-pager, journalctl -p err --since "1 hour ago", and dmesg -T | tail -100 often give quick insights into recent errors.
When should a server be rebooted?
When less aggressive mitigation has failed or the system is entirely unrecoverable. Rebooting without diagnosis can erase evidence and hide the root cause.
