Stop Manually Checking for Server Updates: Automate With ...

☁️ Pre-Flight Checklist

Before we taxi down the runway, here’s your flight plan. Keep this handy to navigate your flight path. Welcome aboard the cloud!

Enjoy your flight! ☁️

You're running a production server. It's humming along fine. Memory is healthy at 27%, disk usage is reasonable, and your containers are all green. Then one morning you realise you haven't checked for updates in three weeks.

Sound familiar? Most DevOps engineers face this pattern: updates pile up, you forget to check, and when you finally remember, there's a backlog of patches waiting. The real problem isn't the updates themselves — it's the absence of a signal telling you they exist.

In this article, I'll walk you through setting up an automated weekly server health report that lands in your inbox every Sunday morning, complete with pending updates, disk usage, and memory stats. No more manual checks. No more forgotten patches.

Why Automation Matters for Updates

Before diving into the how, let's talk about the why. In production environments, staying on top of updates isn't optional — it's a security and stability requirement. But checking manually creates friction:

You remember sporadically, if at all
Updates pile up and become harder to review
When you finally apply them, there's a larger blast radius
You miss the pattern of what's actually changing on your system

The solution is dead simple: let the system tell you when it needs attention. A weekly email report transforms this from a thing you have to remember into a thing that pulls your attention at a consistent time.

The Architecture

Here's what we're building:

A Bash script runs every Sunday at 6am UTC (customisable to your timezone). It checks for available updates, captures disk and memory usage, and emails you a digest. You review the list during your morning coffee, and if nothing is urgent, you schedule the updates for a low-traffic window. If there are security patches, you can apply them immediately.

The beauty of this approach is that it's dead simple — just a few bash commands, a Gmail app password, and a cron job. No external services, no complex infrastructure.

Prerequisites

You'll need:

An Ubuntu server (22.04 or later works fine) SSH access with sudo privileges
A Gmail account with 2FA enabled (for the app password)
About 10 minutes of setup time

This approach works on OCI, AWS, DigitalOcean, or any Ubuntu VPS. The only external dependency is Gmail's SMTP server, which is rock solid.

Step 1: Create a Gmail App Password

Gmail's SMTP server requires authentication. Instead of using your actual Gmail password, you create an app-specific password that you can revoke later if needed.

First, enable 2-Step Verification on your Google Account if you haven't already. Then:

Go to your Google Account → Security
Scroll to "App passwords" (only visible if 2FA is enabled)
Select "Mail" and "Windows Computer" (the actual device doesn't matter)
Google generates a 16-character password like lqxu mdsxjwbj mast
Copy this password as you'll use it in the next step.

This approach is much safer than storing your actual Gmail password on the server.

Step 2: Install Mail Utilities

SSH into your server and install the tools we need:

sudo apt-get update
sudo apt-get install -y msmtp msmtp-mta mailutils

This installs msmtp (a lightweight mail client), msmtp-mta (a mail transport agent), and mailutils (mail utilities). The download is about 70MB and takes a minute or two.

Step 3: Configure Gmail SMTP

Create the msmtp configuration file:

sudo nano /etc/msmtprc

Paste this configuration, replacing the placeholder email and password with yours:

defaults
auth           on
tls            on
tls_trust_file /etc/ssl/certs/ca-certificates.crt
logfile        /var/log/msmtp.log

account        gmail
host           smtp.gmail.com
port           587
from           your-email@gmail.com
user           your-email@gmail.com
password       your-app-password-here

account default: gmail

The key points here:

auth on enables SMTP authentication tls on encrypts the connection
port 587 is Gmail's submission port (not 25 or 465)
password is the 16-character app password (without spaces)

Save this file with Ctrl + O, then Enter, then Ctrl + X.

Now lock down the file so only root can read it:

sudo chmod 600 /etc/msmtprc

This is important because the file contains your credentials.

Step 4: Create the Update Notification Script

Create a new script that will gather server stats and send you an email:

sudo nano /usr/local/bin/update-notify.sh

Paste this script:

#!/bin/bash
RECIPIENT="your-email@gmail.com"
HOSTNAME=$(hostname)

# Refresh package lists
apt-get update -qq

# Get the list of upgradable packages
UPDATES=$(apt list --upgradable 2>/dev/null | grep -v "Listing...")
COUNT=$(echo "$UPDATES" | grep -c "/" || true)

# Get system stats
DISK=$(df / | awk 'NR==2 {print $5}')
MEMORY=$(free -h | awk '/^Mem:/ {print $3 "/" $2}')

# Send email with all the information
echo -e "Subject: [$HOSTNAME] Weekly Server Report\n\nDisk: $DISK\nMemory: $MEMORY\nPending updates: $COUNT\n\n$UPDATES" \
  | msmtp "$RECIPIENT"

Let me break down what this script does:

The first section sets your email address and gets the hostname so you can identify which server the email came from. The apt-get update -qq silently refreshes the package lists without noisy output.

The second section uses apt list --upgradable to get all available updates and counts them. We filter out the "Listing..." header line that apt adds.

The third section captures two key metrics: disk usage (as a percentage) and current memory usage (like 1.4Gi/11Gi). These give you a weekly pulse on resource usage.

Finally, we construct an email with all this information and pipe it through msmtp. The format is deliberate — the subject line includes the hostname so you can glance at the email and know which server it's from.

Save the file and make it executable:

sudo chmod +x /usr/local/bin/update-notify.sh

Step 5: Test the Script

Before scheduling it in cron, test it manually:

sudo /usr/local/bin/update-notify.sh

Check your inbox (may take 10-30 seconds). You should receive an email titled [your_hotname] Weekly Server Report with your disk, memory, and update counts.

If the email doesn't arrive, check the msmtp log:

sudo cat /var/log/msmtp.log

Common issues:

Authentication failed: Your app password is wrong. Double-check it in Gmail's security settings, and make sure you removed spaces when pasting it into msmtprc.
TLS error: Less common, but if you see this, try tls_trust_file /etc/ssl/certs/ca-certificates.crt (which is already in the config above).
Timeout: Your firewall might be blocking port 587. Contact your hosting provider or check firewall rules.

Once the test email arrives, you're ready to schedule it.

Step 6: Schedule With Cron

echo "0 6 * * 0 root /usr/local/bin/update-notify.sh" | sudo tee /etc/cron.d/update-notify

Breaking down the cron expression 0 6 * * 0:

0 = minute 0
6 = hour 6 (UTC)
* = any day of month
* = any month
0 = Sunday

So this runs at 6am UTC every Sunday. Want 8am instead? Change the 6 to 8. Want Monday? Change 0 to 1.

You can verify the job is scheduled:

sudo cat /etc/cron.d/update-notify

Understanding Your Update Report

When the email arrives, you'll see something like:

Disk: 28%
Memory: 1.4Gi/11Gi
Pending updates: 9

containerd.io/jammy 2.2.4-1~ubuntu.22.04~jammy arm64 [upgradable from: 2.2.3-1~ubuntu.22.04~jammy]
docker-ce/jammy 5:29.5.2-1~ubuntu.22.04~jammy arm64 [upgradable from: 5:29.5.1-1~ubuntu.22.04~jammy]
docker-ce-cli/jammy 5:29.5.2-1~ubuntu.22.04~jammy arm64 [upgradable from: 5:29.5.1-1~ubuntu.22.04~jammy]
...

Here's how to interpret it:

Disk at 28% means you're using 28% of available space. Generally, you want to stay below 80% — above that and your system can get sluggish. If you see disk usage above 90%, you should start cleaning up immediately, as you're running dangerously low on free space.

Memory at 1.4Gi/11Gi means you're using 1.4 gigabytes out of 11 gigabytes available. For most workloads, anything under 80% is healthy. If you regularly see 90%+, your containers might be memory-constrained.

Pending updates: 9 tells you how many packages have updates available. This is where you make a decision: are they security patches or minor version bumps? The detailed list below helps you decide.

The package list shows exactly what's available. Look for the word "security" in the version — those should go to the front of your queue. Docker updates are usually safe to apply, but they may require a daemon restart. System library updates are generally safe on non-kernel packages.

Applying Updates Safely

Once a week you'll get this email. Here's the decision tree:

If there are only security updates: Apply them as soon as possible. These are critical.

sudo apt-get upgrade -y

If it's mostly minor version bumps (like Docker 29.5.1 → 29.5.2): Apply them during your next scheduled maintenance window, or wait until the following week if you prefer to batch them.

If there are kernel updates: Kernel updates require a reboot. Schedule them during a low-traffic window and plan for a few minutes of downtime.

If there are no updates: Great! Your email will tell you everything is current, so you can relax for another week.

After applying updates, verify your containers are still healthy:

sudo docker ps --format "table {{.Names}}\t{{.Status}}"

You want to see "Up" for all your services. If something crashed, you'll see "Exited" or an error state, which tells you something went wrong with the update.

Pro Tips

Customise the timing: Change the 6 in the cron expression to whatever time works for you. I recommend early morning (before traffic peaks) so you can apply critical updates if needed.

Add more metrics: The script can be extended to include CPU load, network stats, or Docker container count. Just add more lines that echo to the email.

Combine with unattended-upgrades: For security patches only, you can use Ubuntu's unattended-upgrades to apply them automatically at 3am and reserve your weekly email for the rest. This gives you defence in depth without manual effort.

Monitor the logs: If you want to see what was emailed and when, check:

sudo tail -f /var/log/msmtp.log

Revoke the app password: If you ever suspect it's been compromised, delete it in Gmail's security settings and generate a new one. The old password immediately stops working.

Wrapping Up

You've now got a system that pulls server health to your attention on a predictable schedule. No more guessing when to check. No more surprises from stale updates. Every Sunday morning, you get a digest that tells you exactly what needs attention.

This approach scales from one server to dozens. If you manage multiple machines, you can set each one up with its own cron job, and you'll get separate emails for each server. The subject line includes the hostname, so you can quickly triage across your fleet.

The setup takes about 10 minutes the first time. After that, it runs on autopilot. That's the beauty of automation – small upfront investment, big payoff over time.

Your future self will thank you when you're not scrambling to remember the last time you patched production.

Cover photo by Taylor Vick on Unsplash

推荐订阅源

DEV Community