7 Bash Scripts Every Devops Engineer Should Have

A production server rarely fails in a convenient way.

A disk suddenly fills up. A process consumes all available CPU. A network connection becomes unreliable, or an SSH account needs to be investigated after a suspicious login.

When this happens, a DevOps engineer usually does not start by writing a new monitoring system. The first response is often much simpler: connect to the server and investigate what is happening.

The problem is that the investigation itself can become repetitive.

Running df, du, ps, ss, journalctl, checking authentication logs, and collecting system information manually may seem trivial on one server. But during an incident, repeatedly remembering which commands to run, in which order, and how to collect the results wastes time and makes investigations inconsistent.

This is where Bash becomes useful.

Instead of treating Bash as a language for small one line commands, we can use it to turn recurring operational procedures into reusable tools. The goal is not to replace observability platforms or configuration management systems. The goal is to create lightweight scripts that can be executed directly on a server when an engineer needs fast, consistent information.

In this project, we will build a collection of 7 practical bash scripts for common DevOps operations:

• Investigating disk usage

• Collecting incident context

• Inspecting log activity within a specific time window

• Investigating network paths

• Auditing running processes

• Auditing SSH access

• Cleaning up unnecessary system resources

Each script is designed around a real operational problem.

By the end of this project, we will have a small Bash toolkit that can turn common server investigations from a collection of ad-hoc commands into repeatable operational workflows.

The code snippets in this article focus on the important parts of the implementation. For the complete Bash Scripts you can find the full source code in the repository below.

GitHub Repository: https://github.com/muhammadyulasfipahrizal/terraform-setup

1. Disk Investigator

disk-investigator.sh is a filesystem investigation script designed to answer a common question during Linux server incidents:

What is consuming the disk, and where should I investigate next?

Instead of running several commands manually, the script combines filesystem, inode, directory, file, and modification-time information into a single investigation report.

The script accepts three parameters:

• --path controls which directory or filesystem is investigated.

• --top controls how many results are displayed.

• --min-size defines what qualifies as a large file

The script starts with the filesystem itself. It reports the filesystem type and basic capacity information, then checks inode consumption. This distinction is important because a server can run out of inodes even when there is still available disk space.

It then moves from a broad view to more specific information:

1. Filesystem capacity and inode usage

2. Largest directories

3. Largest files

4. Large files modified within the last 24 hours

2. Incident Context

incident-context.sh collects the current state of a Linux server into a single incident report.

During an incident, the first challenge is often not finding the exact root cause immediately. It is establishing what the server looked like when the problem occurred.

Instead of manually running commands such as uptime, free, df, ps, ip, ss, systemctl, and journalctl, this script collects those signals together and presents them as one structured snapshot.

The report is organized around the main areas an engineer would typically investigate:

The script also introduces an important operational concept: time-bounded investigation.

By default, it collects journal and kernel information from the last 30 minutes, but the window can be changed with --since, for example:

sudo ./incident-context.sh --since "2 hours ago"

This prevents the report from becoming an uncontrolled dump of historical logs. During an incident, the most useful information is usually the information surrounding the period in which the failure occurred.

The script can also write the collected information to a report file:

sudo ./incident-context.sh --output incident-report.txt

The result is a reusable incident snapshot: instead of starting an investigation with an empty terminal and a list of commands to remember, the engineer can generate a consistent baseline of the server's state and use it as the starting point for deeper investigation.

3. Log Window

log-window.sh is a focused log investigation tool for extracting only the log entries that are relevant to an incident.

When an application produces thousands of log lines, searching the entire file manually can make an investigation unnecessarily difficult. Usually, an engineer already has some context about the problem:

• when the problem happened,

• what severity the event had, or

• a phrase associated with the failure.

Instead of reading the entire log file, this script allows those clues to become filters.

The script supports four independent filters:

These filters can be combined like this:

./log-window.sh --file ../logs/dummy.log \
--level WARN \
--contains "Database response time increased" \
--start "2026-08-18 10:07:00"  --end "2026-08-19 10:09:00"

4. Network Path

network-path.sh is a network troubleshooting script that checks connectivity to a destination layer by layer, instead of treating connectivity as a single yes-or-no question.

A connection failure can happen at different points. DNS might fail to resolve the hostname, the routing table might not provide a valid path, the TCP port might be unreachable, or an application-layer problem might occur after the connection succeeds.

If DNS fails, there is no reason to continue testing TCP. If DNS and routing succeed but TCP fails, the investigation can focus on connectivity, firewall rules, security groups, or the destination service rather than the application itself.

The script therefore produces a more useful result than simply:

Connection failed

It can identify a failure boundary such as:

DNS      PASS
Route    PASS
TCP      FAIL
TLS      SKIP
HTTP     SKIP

Failure detected at: TCP

The script requires a destination host and TCP port:

./network-path.sh \
    --host google.com \
    --port 443 \
    --https

5. Process Audit

process-audit.sh provides a deeper view of how running processes are consuming system resources.

Commands such as top and ps are excellent for quickly identifying CPU or memory usage, but during troubleshooting we often need more context. A process consuming resources may also have an unusually high number of file descriptors, threads, context switches, or a large resident memory footprint.

This script collects those signals for every accessible process and turns them into a structured resource audit.

The script can rank processes by different resource dimensions:

sudo ./process-audit.sh --sort cpu
sudo ./process-audit.sh --sort memory
sudo ./process-audit.sh --sort fd
sudo ./process-audit.sh --sort threads

6. SSH Access Audit

ssh-access-audit.sh is a read-only security audit tool for examining how users can access a Linux server through SSH and what privileges they have after gaining access.

SSH is often the primary entry point for administrators and automation. Because of that, troubleshooting SSH access should not only ask:

Is SSH running?

It should also answer:

Who can access the server, how can they authenticate, what keys are authorized, and what privileges do those users have?

The script approaches SSH access from several layers:

The script evaluates the effective SSH configuration using sshd -T, covering authentication settings such as root login, password authentication, public-key authentication, and keyboard-interactive authentication.

Finally, findings are classified as HIGH, MEDIUM, or INFO so critical security issues can be prioritized.

7. System Cleanup

system-cleanup.sh is a safe filesystem cleanup tool that identifies files that may be consuming unnecessary disk space and removes them only after explicit confirmation.

Disk cleanup is inherently risky because deleting the wrong file can cause service failures or data loss. Instead of immediately running destructive commands such as rm -rf, the script separates cleanup into two phases:

It looks for cleanup candidates in common locations:

• /tmp

• /var/tmp

• APT package cache

• Old compressed logs

• Systemd journal usage

With this script, engineers don't need to manually search for and delete files, reducing the risk of accidentally removing important data. The script only deletes discovered candidates from predefined safe locations after explicit confirmation.

Conclusion

These 7 bash scripts turn common Linux administration tasks into a practical operational toolkit.

Each script provides a focused capability:

• Disk Investigator helps identify what is consuming storage.

• Incident Context provides a structured view of the server state.

• Log Window makes relevant events easier to isolate.

• Network Path helps pinpoint where connectivity breaks.

• Process Audit reveals which processes are consuming system resources.

• SSH Access Audit exposes potential access and privilege risks.

• System Cleanup makes disk cleanup safer and more controlled.

The biggest benefit comes from using them together. Instead of relying on individual commands and ad-hoc procedures, engineers have a consistent set of tools for investigation, diagnosis, security auditing, and cleanup.

More importantly, these scripts can become building blocks for larger operational practices. They can be extended with additional checks, integrated into automation, or adapted to the specific standards of an organization's infrastructure.

A command that you run once is useful.

A well designed script that consistently performs the same set of commands is an operational asset.

You can find the source code for this article in my github repository:
Github Repository