You know that feeling when you spot something destined for the recycling bin and think, “Wait, I could actually use that”? I’ve had an old Dell Precision T5500 sitting around collecting dust (you know, because I hate throwing stuff like that away).
This thing was a beast from the mid-2000s—built like a tank, the kind of workstation that could handle 3D rendering and video editing without breaking a sweat back when that was impressive. Looking at the specs, I realized it could handle something I’d been meaning to set up: a dedicated Linux server for Docker container development and running an n8n automation instance.
The logic was sound. Sure, it’s not the most power-efficient machine, but it was free, and I already had the hardware. I plunked it down on the floor in my office and got to work.
The Problem Nobody Warned Me About
Fast forward a few days. Everything’s running smoothly—Docker containers are spinning up, n8n is humming along, and I’m feeling pretty clever about the whole thing. Then one afternoon, I try to SSH into the server and… nothing. It’s completely unresponsive. Not responding to pings. Just dead.
My first thought was “great, what did I break?” But as I troubleshot, trying to figure out what went wrong, the machine suddenly came back online. Weird. I SSH’d in to check the logs, looking for errors or crashes that might explain the outage.
Then I ran sensors to see if maybe something hardware-related had failed. Core 0 was sitting at 107°F. Core 10 at 127°F. And the GPU… 185°F.
Oh. Oh.
The thing had been overheating and basically thermal-throttling itself into oblivion. That’s not a bug—that’s the machine protecting itself. But it also meant that at some point, the temperatures could spike high enough to cause real damage. And I’d have zero warning before it happened. No visibility, no alerting, nothing.
I could leave the server running 24/7, but I needed peace of mind. I needed to know if temperatures spiked before they caused real damage.
The Solution: Building a Temperature Monitoring Script
I decided to build a bash script that would monitor CPU temperatures continuously and alert me if things got dicey. But here’s the thing—I didn’t want an email alert per core. If all four cores are running hot, I don’t need four separate emails. I needed one bundled alert that gave me the full picture at a glance.
I thought a text message would work best, but I’m not about to pay for a service just for this. So email would work, and as it turns out, AT&T has an email-to-text bridge. But that didn’t work all that well. So I set up a Discord channel and use the webhook feature to get instant notifications on my phone.
The Basic Idea
The script does a few straightforward things:
- Reads CPU temperatures from
sensors - Compares them against warning and critical thresholds
- Bundles all the hot cores into a single message
- Sends alerts via email and/or Discord
- Optionally shuts down the server before damage happens
Let me walk you through how it actually works.
Step 1: Capturing Sensor Data
sensors_output=$(sensors -f) echo "$sensors_output"
This runs the sensors command with the -f flag to get temperatures in Fahrenheit. The output looks something like:
Core 0: +84.2°F (high = +185.0°F, crit = +203.0°F) Core 1: +80.6°F (high = +185.0°F, crit = +203.0°F)
Then we extract just the core temperature lines:
core_lines=$(echo "$sensors_output" | grep -E '^Core [0-9]+:')
This gives us a clean list of just the lines we care about.
Step 2: Parsing Each Core
Here’s where it gets a bit clever. We loop through each core and extract the temperature value:
while read -r line; do
core=$(echo "$line" | awk '{print $1 " " $2}' | sed 's/://') # e.g., "Core 0"
temp=$(echo "$line" | grep -oP '\+\K\d+(\.\d+)?' | head -1 | cut -d'.' -f1)
done <<< "$core_lines"
The grep -oP '\+\K\d+(\.\d+)?' part is doing the heavy lifting—it’s extracting just the number from something like +84.2°F. The \+\K means “find a plus sign, then match what comes after” (that’s the lookahead). Then we cut -d'.' -f1 to grab just the integer part, so we’re comparing whole numbers.
Step 3: Building Bundled Alerts
Instead of sending an alert for every core, we accumulate them into a single message:
if [ "$temp" -ge "$CRITICAL_TEMP" ]; then
warning_message="${warning_message}CRITICAL: $core at ${temp}°F\n"
critical_alert=1
elif [ "$temp" -ge "$WARNING_TEMP" ]; then
warning_message="${warning_message}WARNING: $core at ${temp}°F\n"
fi
So if cores 0, 1, and 9 are all hot, the warning_message variable accumulates all three. Then, at the end, we send one alert with all the information:
⚠️ **CPU Temperature Warning** WARNING: Core 0 at 158°F WARNING: Core 1 at 160°F WARNING: Core 9 at 159°F
Much cleaner than three separate alerts, right?
Step 4: Sending Alerts
The script checks what alert methods are configured and sends to all of them:
if [ -n "$warning_message" ]; then
# Send email alert if configured
if [ -n "$EMAIL_ADDRESS" ]; then
echo -e "CPU Temperature Warning:\n\n$warning_message" | \
mail -r "${EMAIL_FROM}" -s "CPU Temperature Warning" "$EMAIL_ADDRESS"
fi
# Send Discord alert if configured
if [ -n "$DISCORD_WEBHOOK" ]; then
curl -s -X POST -H 'Content-type: application/json' \
--data "{\"content\":\"⚠️ **CPU Temperature Warning**\n\n$warning_message\"}" \
"$DISCORD_WEBHOOK"
fi
fi
The cool part? You can use either alert method or both.
Step 5: The Nuclear Option
If things hit the critical threshold, the script can shut the server down gracefully before damage occurs:
if [ $critical_alert -eq 1 ]; then # Send alerts... # Then shut down sudo shutdown -h now fi
I have this commented out by default because I want to test it first, but when you enable it, this will literally power down the machine before temperatures get dangerous.
Setting It Up: Configuration Over Code
The details to setup your own instance are in configuration, either a file or environment variables.
The script first looks for a cpu_temp_monitor.conf file in the same directory:
CONFIG_FILE="${SCRIPT_DIR}/cpu_temp_monitor.conf"
if [ -f "$CONFIG_FILE" ]; then
source "$CONFIG_FILE"
fi
If that doesn’t exist, it falls back to environment variables:
: "${EMAIL_ADDRESS:=${CPU_MONITOR_EMAIL}}"
: "${DISCORD_WEBHOOK:=${CPU_MONITOR_DISCORD_WEBHOOK}}"
This way, you can copy the .example file, fill in your own settings, and never commit secrets to git. Perfect.
Running It on Schedule
Manually running this script once is cool. Running it automatically every 5 minutes? That’s where the real peace of mind comes in.
I added a cron job:
*/5 * * * * /home/jonathan/scripts/cpu_temp_monitor.sh 158 176 >/dev/null 2>&1
This runs the script every 5 minutes with thresholds of 158°F for warnings and 176°F for critical alerts. (If you’re wondering: 158°F is about 70°C, which is a reasonable warning temperature; 176°F is 80°C, which is safely below the hardware limits but aggressive enough to give you time to act.)
The >/dev/null 2>&1 at the end just tosses the output so you don’t get flooded with cron email if something goes wrong.
What I Learned
This whole project taught me something important: sometimes the best solutions aren’t complicated. This script is just bash, some regex, and curl. Nothing fancy. But it does exactly what I needed.
And honestly? Seeing that Discord notification pop up on my phone when something’s getting hot—knowing that my server’s got an automated guardian watching its back—that’s worth the hour I spent putting this together.
The Dell sitting on my office floor isn’t the most elegant server setup. It’s loud, it’s power-hungry, and it runs hot. But it works. And now it works safely—I know exactly when it’s getting stressed, and it won’t just drop offline without warning. That’s the win.
If you’ve got old hardware sitting around and you’re thinking about repurposing it, don’t let temperature anxiety hold you back. Monitor it, alert on it, and let automation take care of the rest.
Want to use this script for your own setup? The full code, config template, and documentation are available on GitHub. Just copy the config file, fill in your Discord webhook (or email address, or both), and schedule it in cron. Honestly, it takes about five minutes to get running.
And hey—if you find ways to improve it, send a pull request. I’m always down for suggestions.