← Blog

Server resource monitoring with a cron job and no agent

Most VPS monitoring stories end the same way: you install an agent, wire up a collector, add a Prometheus exporter, and then spend an afternoon keeping it all running. A small server running a SaaS side project does not need that. Three numbers — disk, CPU, memory — sent once an hour via curl is enough to catch the problems that actually matter.

What you actually need to know

Servers fail in slow and boring ways. Disk fills up over weeks. Memory creeps upward after a bad deploy. CPU spikes every hour when a job runs longer than it should. None of that needs real-time telemetry. An hourly sample is almost always enough to see the pattern before it becomes an outage.

The goal is simple: know that disk is at 78% today, was at 74% last week, and is trending in a direction you should care about. A chart and a threshold alert gets you there.

Set up three metrics in Umlogger

Sign up, open the console, and create these metrics — all of type value:

  • server-disk-usage
  • server-cpu-usage
  • server-memory-usage

Copy the pmk_…key from each metric's detail page. That key is all the script needs — no secret key, no agent config.

The script

Create /usr/local/bin/umlogger-monitor.sh:

#!/bin/bash

PMK_DISK="pmk_YOUR_DISK_KEY"
PMK_CPU="pmk_YOUR_CPU_KEY"
PMK_MEM="pmk_YOUR_MEM_KEY"

BASE="https://data.umlogger.com/api/m"

# Disk usage % of /
DISK=$(df / | awk 'NR==2 {gsub(/%/,"",$5); print $5}')

# CPU usage % — reads /proc/stat directly, works on any Linux distro
CPU=$(awk '/^cpu / {idle=$5; total=$2+$3+$4+$5+$6+$7+$8+$9+$10; printf "%.0f", (1-idle/total)*100}' /proc/stat)

# Memory usage %
MEM=$(free | awk '/^Mem:/ {printf "%.0f", $3/$2 * 100}')

curl -sf "${BASE}?key=${PMK_DISK}&value=${DISK}" > /dev/null
curl -sf "${BASE}?key=${PMK_CPU}&value=${CPU}" > /dev/null
curl -sf "${BASE}?key=${PMK_MEM}&value=${MEM}" > /dev/null

Make it executable:

chmod +x /usr/local/bin/umlogger-monitor.sh

Run it once to verify the values look sane before handing it to cron:

bash /usr/local/bin/umlogger-monitor.sh

Wire it to cron

crontab -e

Add one line:

0 * * * * /usr/local/bin/umlogger-monitor.sh

That fires at the top of every hour. After the first few runs, the charts in Umlogger will start filling in.

A note on the CPU calculation

top -bn1 looks tempting but its output format varies across distributions and Ubuntu versions — you will waste ten minutes figuring out which column is idle. Reading /proc/stat directly is more reliable: $5 is the idle counter, everything else is work. Divide idle by total ticks, subtract from 1, multiply by 100. On a quiet VPS the number will often be 1–5%, which is correct.

Add alerts for the cases that matter

On each metric's detail page, add a threshold alert. Sensible starting points:

  • Disk above 85% — gives you time to clean up before things break
  • Memory above 90% — catches a leak or runaway process before the OOM killer acts
  • CPU average above 80% over the last hour — distinguishes a real problem from a momentary spike

The "missing data" alert is useful too: if the script stops running — the server is down, cron broke, or disk filled up completely — you get an email within the hour.

Why not just use Netdata, Prometheus, or the cloud provider's built-in monitoring?

You can. UpCloud, for example, has basic resource graphs in the control panel. But those are separate from wherever you track your application metrics. Sending server health to Umlogger alongside your SaaS metrics — signups, MRR, job success — means one place to check in the morning. The daily digest email can include all of it.

Netdata and Prometheus are genuinely good tools. They are also tools you have to run, maintain, and occasionally debug at inconvenient times. Three curl calls in a cron job have a very short failure mode list. More background-job patterns are in our cron & worker use case.

The whole setup takes about ten minutes

Create three metrics, paste the script, add the cron line, set the alerts. After that it runs on its own and emails you if anything goes wrong. For a side project running on a single VPS, that is the right level of investment.