Know when a scheduled job never ran
A backup that silently stops running looks exactly like a backup that works — until you need it. Your job pings AlertSleep when it finishes; we alert you when that ping does not arrive.
Nightly billing run
UP0 3 * * * /usr/local/bin/billing-run \
&& curl -fsS https://api.alertsleep.com/v1/ping/YOUR-TOKENOne line in your crontab
No agent, no library, no outbound firewall rules beyond plain HTTPS. If the machine can reach the internet, it can report in.
Create a check
Describe when the job should run and how late it may be before you want to hear about it. You get back a unique ping URL.
Call the URL when the job finishes
Append a single curl call to the command you already run. Nothing else about the job changes.
We watch the silence
AlertSleep checks every minute for jobs that are past due. Miss the window and the alert goes out — including the first time a job stops running.
Two ways to say when a job should run
Pick whichever matches how you think about the job.
Every N minutes
For jobs that run on an interval: a queue drain every five minutes, a sync every hour. State the interval and nothing else.
A cron expression
For jobs tied to the clock or the calendar. Paste the same expression your crontab uses and the check follows it exactly.
Your timezone, not ours
A cron schedule is evaluated in the timezone you choose, so a job pinned to 03:00 local time stays at 03:00 across a daylight saving change.
A grace period
Real jobs start late and run long. Set how much lateness is normal and only genuine overruns raise an alert.
Three signals, any HTTP client
GET, POST and HEAD all work, so curl, wget, PowerShell or a two-line HTTP call from inside the job are equally valid.
Success
The job finished. This is the only signal a check needs — everything else is optional.
https://api.alertsleep.com/v1/ping/YOUR-TOKEN
Start
Call this when the job begins and AlertSleep records how long each run takes, not just that it happened.
https://api.alertsleep.com/v1/ping/YOUR-TOKEN/start
Failure
The job ran and knew it had failed. An explicit failure alerts immediately instead of waiting for the schedule to lapse.
https://api.alertsleep.com/v1/ping/YOUR-TOKEN/fail
Optional detail
Send an exit code, a duration or a short message along with the ping. A field we cannot read is dropped and the heartbeat is still recorded — a malformed extra never costs you the signal itself.
curl -fsS -X POST \
https://api.alertsleep.com/v1/ping/YOUR-TOKEN \
-d exit_code=0 \
-d duration_ms=48213 \
-d message="1482 invoices"When the ping does not arrive
Cron checks alert by email and in your AlertSleep dashboard.
Email alert
Sent once when the check goes down, with the schedule, the grace period and the time of the last ping received.
In-app notification
The same alert lands in your notification list, so a check that failed overnight is still visible the next morning.
Recovery notice
When the job reports in again you are told it recovered. No alert repeats while a check stays down.
Cron checks on every plan
Including the free one. No credit card to find out whether your jobs are actually running.
Frequently Asked Questions
What is cron monitoring?
Cron monitoring — also called heartbeat or dead man's switch monitoring — watches for a signal that is supposed to arrive. Your scheduled job calls a URL when it finishes; if that call does not arrive on time, you are alerted. It is the inverse of uptime monitoring, where we call you.
Why not just check the exit code in my script?
An exit code only exists if the job ran. The failures that hurt are the ones where nothing ran at all: the crontab entry was deleted, the server was rebuilt, the container never started, the disk filled. A job that produces no output and no error is indistinguishable from a healthy one unless something is watching for its absence.
Does it work with Kubernetes CronJobs, systemd timers or Windows Task Scheduler?
Yes. Nothing about the check assumes crontab — it only needs the job to make an HTTPS request when it finishes. Any scheduler that can run curl, or any program that can make an HTTP call, can report in.
What if the job runs but takes much longer than usual?
Call the start endpoint when the job begins and the success endpoint when it ends, and each run's duration is recorded. The grace period decides how much lateness is tolerated before the check is considered down.
Is the ping URL a secret?
Yes. The token in the URL is the only credential on an endpoint that accepts unauthenticated calls, so treat it like a password: keep it out of public repositories and out of logs you share.
Find out tonight, not next quarter
Add one curl call to your most important scheduled job and know the next time it does not run.
Start Free Monitoring