These are 15 Linux terminal commands I genuinely use in production operations every single day. Not textbook trivia — these are the commands that get me through outages, capacity checks, and late-night troubleshooting when something is on fire. If you work as a Linux sysadmin or DevOps engineer, these are the ones you'll reach for constantly.
I work with a mix of Linux servers, Windows Server, load balancers, and CDN infrastructure. My day usually starts with a quick health check across the fleet, and these commands form the backbone of that workflow. Let me walk you through them grouped by what I actually use them for.
Quick Server Health and Resource Checks
When someone says "the server is slow," I don't guess — I check. These are my first moves.
htop is my go-to instead of top. It gives me a colorized, scrollable view of processes, CPU, memory, and load average. I can sort by any column and kill misbehaving PIDs right from the interface. If htop isn't installed, I install it immediately on any new box.
df -h shows disk usage in human-readable format. I pair it with df -i when I suspect inode exhaustion — especially on mail servers or systems with millions of small files. Inodes run out before disk space more often than people expect.
free -m gives me a quick memory snapshot. I look at available memory, not just used. On modern Linux kernels, cache is reclaimable, so a server showing low "free" memory isn't necessarily in trouble.
uptime is the fastest way to check load average and how long the box has been running. If I see a load of 32 on a 4-core machine, I already know I have a problem before I even open htop.
Network Troubleshooting Commands I Reach For Daily
Network issues are probably 40% of what I deal with. These commands save me hours.
ss -tulpn replaced netstat years ago and it's faster. I use it to see what's listening on which ports and which process owns the socket. The output is clean and instant.
ss -tulpn | grep :443That one-liner tells me if nginx or apache is actually bound to 443, or if something else hijacked it.
curl -I is how I verify HTTP responses without opening a browser. I use it constantly when reconfiguring load balancers or checking CDN behavior:
curl -I https://example.comdig is my DNS weapon of choice. dig +short example.com gives me just the answer. dig @8.8.8.8 example.com lets me query a specific resolver. When DNS changes aren't propagating, this tells me exactly where the problem sits.
mtr combines ping and traceroute into a live, updating view. I run mtr -rwc 100 remote-host for a 100-packet report when users complain about latency to a specific endpoint. It shows me packet loss per hop, which traceroute alone doesn't.
Process and Log Investigation Under Pressure
When something breaks at 2 AM, these commands help me find the culprit fast.
journalctl -u servicename --since "1 hour ago" is how I read systemd service logs without digging through /var/log. I can tail, filter, and time-bound in one command:
journalctl -u nginx --since "30 min ago" --no-pager | tail -50grep -rn is how I search configs. The -r recurses directories, -n shows line numbers. When I need to find which config file has the wrong upstream defined across 20 nginx configs, this is what I run:
grep -rn "proxy_pass" /etc/nginx/tail -f /var/log/syslog is the classic, but I often use tail -F instead — the capital F handles log rotation, so if the file gets rotated while I'm watching, it keeps following the new file. Small detail, big difference during a long incident.
File Transfer and Quick Edits
rsync is irreplaceable. I use it for backups, migrations, and syncing config directories between servers. The flags I use most:
-a— archive mode, preserves permissions, ownership, symlinks-v— verbose output-z— compress during transfer--dry-run— simulate first, always, before touching production
rsync -avz --dry-run /var/www/ user@remote:/var/www/If the dry run looks right, I drop --dry-run and run it for real. This habit has saved me from overwriting production data more times than I can count.
vim is my editor. Not glamorous, but it's on every server I touch. I keep my .vimrc minimal — line numbers, syntax highlighting, and a 4-space tab. When I need to make a quick config change on a box I've never logged into before, I know vim is there.
Security and Access Auditing
last shows me recent login history. When I'm investigating a security concern or just verifying who accessed a box, this is where I start. last -a includes the source IP, which is what I actually need.
find / -perm -4000 -type f 2>/dev/null lists SUID binaries. I run this periodically to spot unexpected SUID files that shouldn't be there. If an attacker drops a SUID root shell, this command finds it.
My Daily Workflow With These Commands
Here's how these fit together in a real scenario. Say I get an alert that a web server is responding slowly.
sshin, runuptime— check load averagehtop— find the CPU-hungry processss -tulpn | grep :443— confirm nginx is still listeningjournalctl -u nginx --since "10 min ago"— check for errorstail -F /var/log/nginx/access.log— watch live traffic patternscurl -I http://localhost— test local response
That sequence takes about two minutes and usually narrows the problem down to either a runaway process, a config issue, or an upstream dependency. As I mentioned before in my earlier posts, having a repeatable diagnostic sequence matters more than memorizing obscure flags.
Final Thoughts
These 15 commands aren't exotic. They're the workhorses. The commands you actually type in production, under pressure, when something needs fixing now. If you're building your own ops toolkit, start here — master these before chasing fancier alternatives.
Note: Always test commands on a non-production box first if you're not 100% sure what they do. rsync with the wrong flags can destroy data faster than you'd think.
Cover image: personalgraphic.official · CC0 (Openverse / kamu malı) · https://www.flickr.com/photos/198895458@N04/53097628210