I had a disk check that worked perfectly. It read the usage, compared it to a threshold, decided things were getting tight — and then did absolutely nothing with that conclusion except append a line to a log file that no human, me very much included, was ever going to open. So when the disk did fill, the script had technically known for hours and had told no one. A monitor that monitors in silence isn't a monitor; it's a diary.
That's the gap this snippet closes, and it's more common than it sounds. Writing the detection logic feels like the hard part, so you stop there, and the alerting — the bit that actually changes your behavior — never gets built. The fix is small: pipe the message into mail so a threshold breach lands in your inbox instead of a logfile. The catch that bites people is environment. Under cron the PATH is minimal and mail may resolve to nothing, or deliver only to a local mailbox you never check, so an alert you "sent" never arrives. The script below sends a real one — with the host, the time, and the top disk consumers in the body — so the next time something goes red, I find out from my inbox, not from a crash. Finding out from a crash instead of from an inbox was a lesson I only needed once.
The alert script that finally got my attention
Save as disk-email-alert.sh (or any name). Set EMAIL and THRESHOLD, install mailutils, then run or cron it.
When the threshold trips
The script logs the percentage, fills MESSAGE with host, time, and du output, sends one email via mail -s …, and prints confirmation. Below is how each piece fits together.
How the message gets built and sent
HOSTNAME=$(hostname) runs the hostname command once and stores the machine name in HOSTNAME, so subject lines and the body clearly say which server had the problem (especially useful if you run the same script on several VPS hosts).
The multi-line MESSAGE variable uses double quotes so Bash expands variables like ${USAGE} and embedded command substitution ($(du …)) when the assignment runs. Literal newlines inside the quoted string appear as real line breaks in the email body.
du -sh /* estimates size per top-level directory (human-readable sizes with -h). Piping through sort -rh and head -5 surfaces the worst offenders inside the alert.
echo "$MESSAGE" | mail -s "[ALERT] Disk Space on ${HOSTNAME}" "$EMAIL" sends standard input as the body, -s sets the subject, and the last argument is the recipient. That is the common mailutils pattern on Ubuntu when local/SMTP delivery is configured.
Important notes
You must have mailutils installed: sudo apt install mailutils
Getting mail working end to end
Step 1 — Install mailutils
When the installer asks, choose Internet Site and use your server hostname. Test delivery: echo "test" | mail -s "test" you@example.com
Step 2 — Create the script
Paste the script, then Ctrl+X → Y → Enter to save.
Step 3 — Set your email and threshold
Edit EMAIL="you@example.com" and THRESHOLD=80 to match your inbox and risk tolerance.
Step 4 — Make it executable
Step 5 — Run it once
Schedule It with Cron
Automation is the point: let the script run while you sleep.
Open your crontab
Example schedules
Cron errors by mail
To capture stderr from a cron line: append 2>&1 | mail -s 'Cron Error' you@example.com so failures land in your inbox.
Gmail relay, combined checks, and rate-limiting
Use Gmail SMTP via msmtp (config example)
Install msmtp, then configure a relay. Example snippet for ~/.msmtprc — use an App Password, not your normal Gmail password:
Point mail at msmtp per your distro docs, or call msmtp directly from the script.
One email for multiple conditions (disk + RAM + CPU)
Collect flags in variables, build a single BODY, and send once if anything is red:
Send at most one alert per 24 hours (lockfile)
Use a sentinel file so a flapping condition does not hammer your inbox:
Why your alerts never arrive
Sending from cron without a full path
Cron’s PATH is minimal. Use absolute paths for the script on the cron line and optionally for mail inside the script ($(command -v mail)).
Mail goes to root@hostname locally
If SMTP is not set up, mail may only deliver locally. Confirm with a test message and watch /var/log/mail.log (path varies).
Understanding the Commands
| Piece | Role |
|---|---|
| hostname | Prints the system hostname for subjects and body |
| date '+%Y-%m-%d %H:%M:%S' | Timestamp for logs and the email body |
| df / | awk … | tr -d '%' | Numeric root filesystem use % for comparisons |
| du -sh /* | sort -rh | head -5 | Top-level directory sizes; helps you act on the alert |
| mail -s "subject" user | Reads body from stdin; sends via configured MTA |
Frequently Asked Questions
How do I send an email from a bash script?
Use the mail command: echo 'Message body' | mail -s 'Subject' you@example.com. Install mailutils first on Ubuntu: sudo apt install mailutils
How do I install mailutils on Ubuntu?
Run: sudo apt update && sudo apt install mailutils. When prompted, choose Internet Site and use your server hostname.
Can I send email alerts automatically from a cron job?
Yes. Schedule your script with crontab -e. When the condition is met, the script sends the email. Add 2>&1 | mail -s 'Cron Error' you@example.com to capture cron output. For HTTP-based monitoring, pair this with the check if website is up script to receive alerts when your site returns a non-200 status.
What if mail command is not found?
Run: which mail — if it returns nothing, install with: sudo apt install mailutils (Ubuntu/Debian) or sudo yum install mailx (CentOS/RHEL).
How do I send email from bash using SMTP (Gmail)?
Use ssmtp or msmtp with your Gmail SMTP credentials. Configure /etc/ssmtp/ssmtp.conf with your gmail address and an App Password (not your real password).
Part of the Server Monitoring collection
