Heartbeat monitoring

Your cron jobs check in. Silence is the alert.

A cron job that crashes is loud. One that quietly stops running tells no one. Silence past the grace period becomes the alert.

Monitoring, inverted: the job reports to us.

Backups, invoice runs, queue sweeps, certificate renewals: the work that keeps a business honest has no URL to probe. When it stops, nothing errors. The backup is simply not there the day you need it.

UptimeStatus gives each scheduled task its own ping URL. The job calls it on every successful run, and we watch the clock. No ping by the deadline means the monitor goes down and an incident opens.

Scheduled tasks 1 overdue
nightly-db-backup
pinged 22 minutes ago
daily · grace 30m
send-invoice-emails
pinged 4 minutes ago
hourly · grace 5m
renew-tls-certs
no ping for 26 hours
daily · grace 60m

Integration is one line at the end of the script.

No SDK, no agent, no config file. The ping endpoint accepts a plain GET or POST with no authentication headers, because the unguessable token in the URL is the credential.

Put the ping after the real work, behind set -e, so it only fires on success. A job that starts but fails halfway stays silent, and silence is what we alert on.

# crontab: nightly database backup at 02:00
0 2 * * * /opt/scripts/backup.sh

# backup.sh
set -euo pipefail
pg_dump "$DATABASE_URL" | gzip > /backups/nightly.sql.gz

# last line: report in. no ping means an alert.
curl -fsS https://uptime-status.org/api/ping/9f2ac81d54e04b7f

What cron monitoring includes.

If it can make an HTTP request, it can check in.

Cron, systemd timers, Kubernetes CronJobs, GitHub Actions on a schedule, a Windows task: the runner does not matter. Anything that can hit a URL once per run gets deadline monitoring, incident history, and alerting through your existing channels.

curl -fsS https://uptime-status.org/api/ping/<token>
FAQ

Cron monitoring, answered.

How is this different from uptime monitoring?

Uptime monitoring reaches out to your endpoint and asks if it responds. A heartbeat monitor is the inverse: it does nothing until your job pings it. That makes it the right tool for work that has no URL to probe, like cron jobs, queue workers, and backup scripts.

What happens when a job misses its check-in?

Once the expected interval plus the grace period passes without a ping, the monitor goes down, an incident opens with the cause recorded as a missed check-in, and your notification channels fire. Deadlines are swept every minute, so detection lands shortly after the grace period ends.

What if my job hangs instead of crashing?

That is exactly the case heartbeats cover. A hung job never reaches the ping line, so it goes silent, and silence past the grace period is the alert. You do not need the job to fail loudly for anyone to find out.

My job runtime varies. Will I get false alerts?

Set the grace period to cover the variance. If a nightly export usually takes 10 minutes but sometimes 25, give it a 30-minute grace and it will only alert when something is genuinely wrong.

Do I need to install anything on my servers?

No. If it can make an HTTP request, it can check in. Add a curl or wget line to the end of the script, or call the URL from whatever language the job is written in.

Is the ping URL safe to put in a script?

The token is an unguessable random string, so nobody can find it by enumeration. Treat it like any other credential: keep it out of public repos, since anyone holding it could ping on behalf of your job.

Start monitoring in under 2 minutes.

No credit card required for the self-hosted, open-source version.