I know my job title doesn’t say DevOps engineer, but at the end of the day, I handle just enough of the Software Development Life Cycle (SDLC) that I have to know some DevOps. I don’t know who told me this, but “don’t ship on Fridays” is so real. It’s the easiest way to mess up your weekend, though I know sometimes you don’t have a choice.
Let me paint you a picture. It’s 4pm Friday and the deployment pipeline is red. The cloud dashboard is just spinning endlessly. It’s just you and your dark terminal, and you’re praying that your server responds.
In these moments, the GUI can’t save you. You can try, but good luck. You need the raw speed of the Linux command line. Having done this a few times over the years, I have built a survival kit of commands. I am not talking about cd and ls; I am talking about tools that have helped in debugging situations like this. I am talking about frozen processes, disk space issues, tracing API failures, and everything in between.
Enjoy.
- tail -f
Setting up the Scene: You deploy a new feature, and the user says it’s not working. You check the dashboard, but it’s delayed by five minutes. You need to see the error as it happens.
The Command:
tail -f /var/log/nginx/error.log
Why I Use It: This streams the log file to your screen. I usually open this in a split terminal window, trigger the bug on the frontend, and watch the error stack trace fly by in real-time. It’s the fastest feedback loop you can get.
2.grep -r
Setting up the Scene: You have 50 different log files or a massive codebase, and you need to find every file that references a specific variable or error code like "payment_failed."
The Command:
grep -r "payment_failed" ./src
Why I Use It: Opening VS Code to search is slow on a remote server. The recursive grep searches through every folder instantly. It tells me exactly which file and line number is guilty.
3.htop
Setting up the Scene: The server is lagging and requests are timing out. You suspect a memory leak or a rogue process eating the CPU.
The Command:
htop
Why I Use It: Unlike the boring top command, htop gives you a colorful, visual bar chart of your CPU and RAM usage. You can see exactly which process—usually a stuck Node.js script—is hogging 99% of the resources.
4.df -h
Setting up the Scene: Your database crashes out of nowhere. No error logs are being written and the server is acting weird.
The Command:
df -h
Why I Use It: This checks your Disk Free space in a human-readable format. Nine times out of ten, the crash happened because the logs filled up the hard drive. This command saves me hours of debugging ghost bugs.
5.netstat -tuln
Setting up the Scene: Your app says "Deployment Successful," but when you visit the URL, you get a "Connection Refused" error.
The Command:
netstat -tuln
Why I Use It: This lists all the ports the server is actually listening on. I often find that while my app is running, it’s listening on port 3000, but Nginx is trying to talk to port 8080. This command reveals the mismatch instantly.
6.history | grep
Setting up the Scene: You fixed a complex bug three days ago using a long Docker command, but now the bug is back and you can't remember the exact syntax you used.
The Command:
history | grep "docker"
Why I Use It: I don't memorize long commands; I just remember one word from them. This searches my entire command history for that word and shows me what I typed last week. It’s my external brain.
7.curl -v
Setting up the Scene: You are trying to debug an API, but you don't know if the issue is the firewall, the browser cache, or the code itself.
The Command:
curl -v http://localhost:3000/api/health
Why I Use It: curl fires a request directly from the server itself. The -v (verbose) flag shows the "handshake," the headers, and the raw response. If this works but the browser doesn't, I know the issue is the firewall or Nginx configuration, not my app logic.
8.kill -9
Setting up the Scene: You found the stuck process using htop, but it refuses to close. You tried asking nicely, and it ignored you.
The Command:
kill -9 [PID]
Why I Use It: This forces the process to stop immediately. It doesn't save data and it doesn't clean up; it just ends it. I use this only when a process is completely frozen and blocking the port. You just need to replace [PID] with the Process ID you saw in htop.
The terminal used to terrify me. I always wanted things to be graphical, but once you work on a few deployments, you realize it’s not just sysadmins who need this stuff. Once you know what you’re doing, you can be very fast.