When you are first learning cloud engineering, you spend a lot of time clicking through beautiful web dashboards.
But what happens when your application crashes at 2:00 AM, the web server goes offline, and the only access you have is an SSH connection to a headless Linux box? You can't rely on a graphical user interface anymore. You need the command line.
Whether you are deploying microservices or debugging a massive production outage, the Linux terminal is where the real DevOps work happens. Here are the 5 Bash commands I use daily to troubleshoot broken servers.
1. tail (Watching Live Logs)
When an application fails, your first instinct should be to check the logs. But log files can be gigabytes in size. Opening a 2GB file in a text editor will crash your server entirely.
Instead, we use tail to look at just the very end of the file. By adding the -f (follow) flag, you can watch the logs stream in real-time.
# Watch the Nginx error log live
tail -f /var/log/nginx/error.log
Why it saves you: You can run tail -f, trigger your broken API endpoint in another window, and watch the exact error message pop up instantly on your screen.
2. grep (Finding the Needle in the Haystack)
If tail is for watching logs live, grep is for searching through them after the fact. grep allows you to search for specific text patterns inside massive files.
If a user complains that their payment failed, you don't want to read a million lines of logs. You just want to see the lines containing the word "ERROR" or "500".
# Find every line containing "500 Internal Server Error"
grep "500 Internal Server Error" /var/log/app/production.log
Pro Tip: Add the -i flag to make your search case-insensitive!
3. awk (Parsing Structured Data)
Sometimes grep gives you too much information. If you have a log file and you only want to extract a specific piece of data—like a list of IP addresses that are spamming your server—you need awk.
awk reads text line by line and splits it into columns (which it calls fields).
# Print ONLY the first column (e.g., the IP address) from an access log
awk '{print $1}' /var/log/nginx/access.log
Why it saves you: When paired with other commands, awk allows you to quickly isolate data so you can block malicious IPs or count exactly how many times a specific user ID failed to log in.
4. chmod (Fixing "Permission Denied")
The most common error you will face as a junior DevOps engineer is Permission denied.
This usually happens because the user running your application (like www-data or ubuntu) does not have the right to read a configuration file or execute a deployment script. chmod (change mode) fixes this by modifying the file permissions.
# Make a deployment script executable
chmod +x deploy.sh
Why it saves you: When your CI/CD pipeline suddenly fails because a script won't run, a quick chmod +x is usually the magic bullet.
5. htop (Monitoring System Resources)
Is your server crashing because of a memory leak in your code, or because the CPU is maxed out at 100%? You need to know immediately.
While top comes pre-installed on most systems, htop is the vastly superior, colorful, and interactive version. It provides a visual breakdown of your CPU cores, RAM usage, and exactly which processes are eating up your resources.
# Launch the interactive resource monitor
htop
Why it saves you: One glance at htop tells you if you need to quickly upgrade your server size (scale up) or if a rogue process needs to be killed immediately.
The Takeaway
You don't need to be a Linux kernel expert to be a great DevOps engineer, but you do need to be comfortable in the terminal. The next time you build a project, skip the UI. Force yourself to navigate the filesystem, check the logs, and manage your scripts entirely through Bash.
☕ Did this reference guide help you out? Buy me a coffee to help keep Atul Codes running!
Top comments (0)