features · heartbeats
Cron job monitoring for the jobs that fail without an error
Cron job monitoring works on a heartbeat model: your job pings a unique URL every time it runs, and AlertPing alerts you when the ping does not arrive on schedule. If the backup never starts, nothing errors. We notice anyway.
one curl line · any language
alertping ▸ heartbeat: nightly-backup
expect every 24 h · grace 15 min
mon 02:00:07 ping received on time
tue 02:00:04 ping received on time
wed 02:00:09 ping received on time
thu 02:11:52 ping received within grace
fri 02:00:00 expected… waiting
fri 02:15:00 no ping · grace expired
fri 02:15:06 ALERT ▸ sms + slack ▸ on-call▌
the heartbeat model
We don't check your job. Your job checks in with us.
External checks can't see inside your servers, and they don't need to. The heartbeat inverts the direction: the job proves it ran. That is why this works for anything behind a firewall, on a laptop, in a container, anywhere with outbound HTTPS.
-
1
Add one line to the end of your job
Each monitor gets a unique ping URL. curl https://hb.alertping.com/p/a81f… as the last line means the ping only fires if everything before it succeeded.
-
2
Set the schedule and a grace period
Expect a ping every hour, every 24 hours, or on a cron expression. The grace period absorbs normal jitter: a backup that sometimes takes 12 extra minutes is not an incident, so give it 15.
-
3
Silence becomes an alert
No ping by schedule plus grace, and your downtime alerts fire: SMS, email, Slack, webhook, through the same escalation chains as every other check.
silent failures
The failures nobody notices for three weeks
A dead cron daemon throws no exception and trips no error tracker. Only the missing heartbeat gives it away.
backups
The backup that stopped in March
Every team has the story: the restore that failed because the dump job had been dying quietly for weeks. A heartbeat on the backup means you find out the first night it skips, not on restore day.
etl · data pipelines
Dashboards that lie politely
When the nightly sync dies, dashboards keep rendering yesterday's numbers and everyone keeps trusting them. A heartbeat per pipeline stage turns stale data into a 2am page instead of a bad quarterly decision. If the pipeline also exposes an endpoint, watch its output with the API monitoring tool for a second opinion.
billing · invoicing
The subscription run that skips a night
A billing job that silently skips one run is revenue that quietly never arrives, and cleanup that takes days. Heartbeats make the run itself observable, separate from whether the code inside it errored.
workers · renewals · reports
Anything scheduled, anywhere
Background workers, cert-renewal scripts, report generators, sitemap builders. Heartbeats complement the outside-in checks of a server monitoring tool: together they cover both directions.
heartbeat questions
Before your first heartbeat
Does this work behind a firewall or VPN?
Yes. The heartbeat is an outbound HTTPS request from your job to us, so nothing needs to be reachable from the internet. If the job can curl a URL, it can be monitored.
What is a grace period and how should I set it?
The grace period is extra time after the expected ping before an alert fires. Set it to the job's normal jitter: a backup that usually lands within 5 minutes of schedule does well with a 15-minute grace. Too short pages you for nothing; too long delays real alerts.
Can I tell the difference between "never started" and "crashed midway"?
Yes. Put the ping at the end of the job and any failure, including never starting, means no ping. For long jobs, send a start ping and a finish ping; a start without a finish points straight at a mid-run crash.
Give every scheduled job a heartbeat
One curl line per job, a grace period you choose, and an SMS the first time a backup, ETL run or billing job goes silent.