How to Troubleshoot a Linux Server in Production
In short: As of September 5, 2026, start by measuring load, memory, disk usage, and service status, then connect the symptom to the logs. For a slow server, full disk, or unstable service, fix the cause before restarting. If the incident recurs or threatens data, call a specialist instead of taking a series of risky actions.
Effective troubleshooting follows a simple sequence: observe, isolate, correct, then monitor. This method prevents a temporarily successful restart from hiding the real problem.
Why start with the server’s overall state?
Before targeting an application, check whether the problem affects the entire machine:
uptime
free -h
df -h
df -i
systemctl --faileduptime exposes the load, free -h notably distinguishes available memory from memory that is simply unused, and df shows available space or inodes. The failed-unit list then reveals services already flagged by systemd.
Record the time of the symptom, the commands you run, and their output. These details make the rest of the diagnosis more reliable, including during an external support intervention.
How do you diagnose a slow Linux server?
Start by observing processes and resources without changing the system:
htop
free -h
df -h
systemctl --failedIn htop, look for a process that continuously monopolizes CPU or memory. In free, focus on the available column. Saturated storage or a failed service can also slow the entire application stack.
Do not immediately restart the most visible process. Check its logs and dependencies first: it may be suffering from the problem rather than causing it.
How do you handle a full disk without making the incident worse?
First determine whether blocks or inodes are exhausted:
df -h
df -i
du -sh /var/*
journalctl --disk-usageThen locate the responsible directory. Logs, caches, local backups, or temporary files can grow, but deleting them blindly may destroy useful evidence or disrupt a service.
Use the system’s intended rotation mechanism, move a backup only after checking it, and confirm that the space has actually been released. Finally, investigate why the growth was not detected earlier.
What should you do when a service keeps going down?
Inspect its status and related messages. Replace nginx.service with the relevant unit:
systemctl status nginx.service
journalctl -u nginx.service --since todayThe systemd status notably tells you whether the service failed, while journalctl -u limits the output to entries for that unit. Find the first relevant error, then check the configuration, resources, and dependencies.
Restart the service only after correcting the cause. If it fails again, preserve the logs and compare the circumstances: load, a recent deployment, storage, network, or a third-party service.
How do you use logs without getting lost?
Filter by time, priority, or unit instead of browsing every file:
journalctl --since today
journalctl -p err..alert --since today
journalctl -u nginx.service --since today
tail -F /var/log/syslogtail -F follows a file by name and attempts to reopen it after rotation. On a distribution without /var/log/syslog, use the systemd journal or the service’s own log file.
An isolated error is not always the cause. Reconstruct the timeline around the first symptom and compare it with system metrics.
When should you call a Linux specialist?
Specialist help becomes appropriate when:
- the server is unreachable or restarts without explanation;
- a critical service fails repeatedly;
- storage fills up again after cleanup;
- an action could compromise data or security;
- the team cannot isolate the cause without taking risks.
In that situation, limit changes, preserve the logs, and provide an accurate timeline. Remote diagnosis is faster when symptoms and attempted actions are documented.
Conclusion
The right reflex is not to restart things at random, but to measure, correlate, and correct. Load, memory, disk, service status, and logs are often enough to isolate the problem. For a recurring or risky incident, specialist intervention protects availability and data better than a succession of temporary fixes.
Sources
Frequently asked questions
What should you check first when a Linux server is slow?
Check the load, available memory, disk space, and failed services before restarting anything. Then correlate the symptom with the logs for the affected service.
What should you do when a Linux server disk is full?
Check space on each file system and possible inode exhaustion, then locate the largest directories. Do not delete logs at random: identify the cause and use the configured rotation policy.
Why does a Linux service keep going down?
The logs and systemd status often reveal a configuration error, an unavailable dependency, or insufficient resources. Fix the cause before restarting the service, then monitor its stability.
When should you call a Linux specialist?
Request help if the server becomes unreachable, incidents recur, or data could be damaged. Avoid improvised deletions and restarts so that you preserve the evidence needed for diagnosis.