What command output should I collect for a Linux server support incident?
A useful incident report ties a clear symptom to the exact server, UTC window and relevant evidence. Gather bounded status output before changing the system, then repeat the same checks after the fix. Avoid full environment dumps, private keys, database exports or unrelated customer logs.
Before you start
- An authorised SSH session on the Linux server.
Instructions
1. Capture a small system baseline
Run these read-only checks close to the incident and describe whether the problem is continuous or intermittent. Include the affected feature and observed response or error.
date -u -Is
uptime
free -h
df -h / /varThese establish time, uptime, memory and relevant filesystem capacity. They do not diagnose the cause by themselves.
2. Add the specific service evidence
Replace the unit with the affected application and keep the excerpt near the event. Redact secrets and personal details before sharing.
systemctl status example.service --no-pager
sudo journalctl -u example.service --since "15 minutes ago" -n 60 --no-pagerInclude the exact error and nearby context, plus the last known good time and any relevant recent change.
Check the result
- Support can identify the symptom, time window, affected scope and reproducible conditions without needing private credentials or unrelated data.
Troubleshooting
- The issue disappears before capture
- Record the observed time and collect retained logs for that window. A later healthy snapshot does not disprove the incident.
- The output is very large
- Narrow the service, time interval and line count instead of sending a whole-server log archive.
Official references
Use the documentation for your installed version when a flag, service name or platform feature differs.