☁️ Pre-Flight Checklist

🌥️ Takeoff

⛅️ Cruising Altitude

🌤️ Landing & Taxi

Why Automation Matters for Updates

The Architecture

Prerequisites

Step 1: Create a Gmail App Password

Step 2: Install Mail Utilities

Step 3: Configure Gmail SMTP

Step 4: Create the Update Notification Script

Step 5: Test the Script

Common issues:

Step 6: Schedule With Cron

Understanding Your Update Report

Applying Updates Safely

Pro Tips

Wrapping Up 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. 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: 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. 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. This approach works on OCI, AWS, DigitalOcean, or any Ubuntu VPS. The only external dependency is Gmail's SMTP server, which is rock solid. 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: This approach is much safer than storing your actual Gmail password on the server. SSH into your server and install the tools we need: 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. Create the msmtp configuration file: Paste this configuration, replacing the placeholder email and password with yours: Save this file with Ctrl + O, then Enter, then Ctrl + X. Now lock down the file so only root can read it: This is important because the file contains your credentials. Create a new script that will gather server stats and send you an email: 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: Before scheduling it in cron, test it manually: 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: 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. Breaking down the cron expression 0 6 * * 0: 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: When the email arrives, you'll see something like: 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. 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. 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: 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. 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: 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. 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 Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse