Monitoring with Bash: System Reporting and Automated Alerting in DevOps
Comprehensive guide to building monitoring systems with Bash: collecting CPU/RAM/Disk/Network metrics, sending alerts via Slack/Telegram/email, logging to CSV, and generating daily reports.
In the previous post, we explored combining Bash and Docker to manage containers and write watchdog scripts for automatic crash recovery. Now, we expand the monitoring scope—not just containers, but the entire system: CPU, RAM, Disk, Network—and alert the team when issues arise.
In DevOps, monitoring is the “eyes” that help you detect problems before they become serious incidents. Many assume monitoring requires Prometheus, Grafana, or Datadog—but in reality, a Bash script combined with cron can collect metrics, send alerts via Slack/Telegram, and generate daily reports without installing any agents.
This article covers collecting core system metrics, sending alerts via webhooks, storing data as CSV for later analysis, and combining everything into a complete daily report script.
Collecting System Metrics
CPU
1
2
3
4
5
6
7
8
9
10
11
12
13
14
# CPU usage from idlecpu_usage(){ top -bn1 | grep "Cpu(s)"| awk '{printf "%.1f", 100 - $8}'| tr -d ','}# 1-minute load averageload_avg(){ awk '{print $1}' /proc/loadavg
}# Number of CPU corescpu_cores(){ nproc
}
========================================
DAILY SYSTEM REPORT
Host: web-prod-01
Date: 2026-09-01 08:00:00
========================================
--- System Info ---
Uptime: up 45 days 3 hours 22 minutes
Processes: 234
TCP Connections: 187
--- Resource Usage ---
CPU: 23.4%
RAM: 67.2% (5412 MB used)
Disk: 72% (58 GB used)
Load: 1.85
--- Thresholds ---
CPU: OK
RAM: OK
Disk: OK
--- Top 5 CPU Processes ---
root 12.3% CPU 0.1% RAM nginx: worker
www-data 8.7% CPU 2.1% RAM php-fpm: pool
mysql 5.2% CPU 15.3% RAM mysqld
root 3.1% CPU 0.8% RAM node /opt/api
root 1.4% CPU 0.2% RAM sshd
--- Top 5 RAM Processes ---
mysql 15.3% RAM 5.2% CPU mysqld
www-data 2.1% RAM 8.7% CPU php-fpm: pool
root 1.8% RAM 0.9% CPU node /opt/api
root 0.8% RAM 3.1% CPU node /opt/api
redis 0.5% RAM 0.3% CPU redis-server
========================================
Deployment Notes & Best Practices
Webhook security: Store Slack webhook URLs and Telegram bot tokens as environment variables or in files with 600 permissions—never hardcode them in scripts.
Metric history: CSV files grow over time. Combine with logrotate or a periodic cleanup script to keep file sizes manageable. You can also use awk or python to analyze trends from the CSV.
Threshold tuning: The defaults (80%/95%) work for most servers. Adjust for specific workloads—batch processing servers may need higher CPU thresholds.
Multi-server monitoring: To monitor multiple servers, combine with SSH from Post 13—run the script on each server and aggregate results in one place.
Escalation: When receiving a CRITICAL alert, the script can call APIs to create tickets in issue tracking systems (Jira, GitHub Issues).
Conclusion
Monitoring with Bash doesn’t need to be complex—just collect the right metrics, set appropriate alert thresholds, and send notifications to the right channels. From reading CPU/RAM/Disk, logging to CSV for trend analysis, sending alerts via Slack/Telegram, to generating daily reports—all within a single Bash script running periodically via cron.
In the next post, we will explore Advanced Bash: Parallel Execution—optimizing script performance with background processes, xargs -P, GNU parallel, and concurrency management.