I started a long job on my own machine, walked off to do something else, and came back a few hours later to a desktop so sluggish the mouse cursor stuttered when I moved it. One process had pinned every core of the i7 and was steadily eating into 64 GB of RAM, and it had been doing it, uncontested, the entire time I was away. By the time the machine felt slow under my hands, the damage — a wasted afternoon, a swap-thrashed box I had to coax back to responsiveness — was already done.
The thing that gets you isn't the runaway process; those happen. It's that a busy machine and a healthy machine feel identical until you're sitting in front of one. CPU and memory pressure leave no trace unless something is sampling them and writing it down. So I built the check below to take a one-shot reading of CPU and RAM, compare each against a threshold, and log a warning the moment either crosses it. One detail worth carrying with you: when the kernel's OOM killer finally reaps a process under memory pressure, it exits with code 137 — that's 128 plus signal 9 — so a 137 in your logs is RAM exhaustion's fingerprint, not a bug in your code. Catching that an hour in, instead of an afternoon later, is the whole reason this runs now.
The monitor I built after my own machine seized up
Paste this into monitor.sh. Adjust THRESHOLD and LOG_FILE if you want a different cutoff or log path.
What each line is actually reading
| Line / piece | What it does |
|---|---|
| THRESHOLD=80 | The percentage at which a warning fires. |
| top -bn1 | Runs top in batch mode for one iteration (non-interactive). |
awk '{print $2}' | Extracts the CPU usage column from top output. |
| free | awk '/Mem:/ ...' | Parses free output to calculate RAM used / total × 100. |
| tee -a "$LOG_FILE" | Prints to stdout and appends to the log file. |
| $DATE | Timestamp so every log entry is traceable. |
Getting it logging on your box
Step 1 — Create the file
Paste the script above, then press Ctrl+X → Y → Enter to save.
Step 2 — Set your threshold
| Threshold | Best for |
|---|---|
| 70% | Early warning on production — gives time to investigate before impact |
| 80% | General-purpose default — recommended for most VPS and cloud instances |
| 90% | Last-chance alert — for workloads with legitimate sustained high usage |
Edit THRESHOLD=80 at the top of the script to match your environment.
Step 3 — Make it executable and test it
You should see output like:
If CPU or RAM is above the threshold, the warning line fires and appends to LOG_FILE. Check the log after a test run:
Step 4 — Schedule with cron
The script only helps if it runs automatically. Open your crontab:
Add one of these lines:
Always redirect cron output to a log
Cron runs silently. Without >> /var/log/monitor-cron.log 2>&1 on your cron line, you will never see warnings from a threshold breach. Redirect both stdout and stderr so every run leaves a trace.
Versions for email, per-process, and graphing
Send an email when CPU or RAM spikes
Same CPU/RAM probes as above, plus a single email whenever either crosses your threshold — useful instead of silently appending log lines. Requires the mail command (typically mailutils on Debian/Ubuntu); see our bash email alert snippet for install tips, SMTP, and Gmail.
Monitor a specific process by name
Pass a substring that appears in ps aux COMMAND column (same idea as grepping logs). Matches every PID whose line contains that substring, sums aggregate %CPU and %MEM, and warns when either crosses a per-watch threshold.
Append JSON log lines for graphing
Every run prints one newline-delimited JSON object and appends it to .jsonl — one record per cron tick — so ingestion tools, log aggregators, or a tiny Python/awk script can build charts.
Where the parsing falls apart
top output format differs between distros
The awk column for CPU usage is $2 on Ubuntu but may be different on CentOS/RHEL or Alpine. Always test your parsing command on the actual target system before scheduling with cron. Run: top -bn1 | grep "Cpu(s)" and count the columns manually.
The script logs warnings but nobody reads the log
Writing to a log file is pointless if nobody checks it. Combine this with the Send Email Alerts from Bash snippet to get notified when thresholds trip. Or pipe cron output to your inbox. When sustained resource pressure is causing service crashes, the restart service watchdog handles automatic recovery between monitoring cycles. A service the kernel kills under memory pressure exits with code 137 — 128 plus signal 9 (SIGKILL), the OOM killer's signature — so a 137 in your logs points to RAM exhaustion, not a code bug.
RAM percentage includes cache/buffers on older systems
On older kernels, free may not show "available" memory correctly. The $3/$2 calculation can overstate usage because Linux aggressively caches disk reads in RAM. On modern Ubuntu (18.04+), this is handled correctly.
Frequently Asked Questions
How do I check CPU usage in bash?
Use top in batch mode: top -bn1 | grep 'Cpu(s)'. For idle as a number, pipe through awk: top -bn1 | grep 'Cpu(s)' | awk '{print $8}'
How do I check RAM usage in Linux?
Use free: free -h is human-readable. In a script: free | awk '/Mem:/ {printf "%.0f", $3/$2*100}' gives RAM usage as a percentage.
How do I get an alert when CPU is too high?
Capture CPU use in a script, compare to a threshold with an if, then schedule the script with cron every minute or hour (or use email from the variations above).
What is a normal CPU usage percentage on a Linux server?
Under 70% is generally healthy for production. Sustained 80–90%+ usually means something worth inspecting with top or htop.
How do I find which process is using the most CPU?
Run: ps aux --sort=-%cpu | head -10 for the top 10. Or run top interactively and press P to sort by CPU.
Part of the Server Monitoring collection
