Cron job monitoring without the PagerDuty bill

Cron jobs fail quietly. The database backup script that stopped running three Tuesdays ago does not page anyone until a customer notices. PagerDuty solves that — for teams with budget and on-call rotation. If you run a handful of scripts on a VPS or a serverless scheduler, you only need to know: did it run, and did it finish?

The cheap pattern: one ping per run

Treat each job like a heartbeat. At the end of the script (or in a finally block), HTTP GET your metric ingest URL with value 1. Umlogger charts arrivals over time; if nothing shows up in the expected window, you configure a "missing data" alert and get an email.

# /etc/cron.d/nightly-backup
0 3 * * * deploy /opt/backup.sh

# last line of backup.sh:
curl -fsS "https://data.umlogger.com/api/m?key=pmk_BACKUP_KEY&value=1" || echo "metric ping failed" >&2

That is the entire integration for many teams — no agent, no collector, no incident.io seat.

Track duration as a value metric

Create a second metric (type value) and send elapsed seconds when the job succeeds:

START=$(date +%s)
# ... job work ...
ELAPSED=$(( $(date +%s) - START ))
curl -fsS "https://data.umlogger.com/api/m?key=pmk_DURATION_KEY&value=$ELAPSED"

Alert when the rolling average spikes — often the first sign a dependency got slow before the job outright fails.

Serverless and GitHub Actions

The same URL works from Lambda, Cloud Functions, or a workflow step. Fire-and-forget fetch in Node, or curl in bash. Point ingest at https://data.umlogger.com in production (see docs for host details).

When PagerDuty still makes sense

If you need 24/7 phone escalation, on-call schedules, and deep integrations with every cloud service, keep PagerDuty (or similar). Umlogger is for the founder who wants email when the 3am cron missed — not a full incident platform. More background-job patterns are in our cron & worker use case.

Create a metric, paste the curl, set a missing-data alert. Most teams are done before the coffee cools.