Cron Job Monitoring with Heartbeats

What cron job monitoring is, and what it isn't

When a website goes down, someone notices. When a scheduled job stops running, nobody does. The nightly database backup, the inventory sync, or the script that emails daily invoices can fail quietly for weeks until the day you need what they were supposed to produce.

Heartbeat monitoring flips website uptime monitoring around. Instead of us requesting a page on a schedule, your job checks in with us. As long as check-ins arrive on time, you're fine. When they stop, something changed: the server was shut down, the crontab was lost in a migration, the script started failing before the last line, or it hung.

What it doesn't do: it doesn't run your jobs, read their logs, time their internal steps, or verify their output. If your backup finishes and pings us, we know it finished. We don't know whether the archive restores.

How a job sends a heartbeat

Each heartbeat monitor gets a unique URL with a secret token. Your job calls it with GET or POST when it's done. For example, at the end of a crontab line:

0 3 * * * /usr/local/bin/backup.sh && curl -fsS https://app.monitoraweb.com/hb/YOUR_TOKEN

The && means the ping only goes out if the script exits successfully. To report a failure yourself, add /fail to the same URL and the job is marked as failed right away:

/usr/local/bin/backup.sh || curl -fsS https://app.monitoraweb.com/hb/YOUR_TOKEN/fail

Treat the token like any other credential. Each heartbeat monitor has its own.

Expected interval and grace period

You choose how often the heartbeat should arrive and a grace period from zero seconds up to seven days. Every minute, MonitoraWeb checks whether the last heartbeat plus the interval plus the grace period has passed. If it has, the monitor goes down at once and your alert list is notified. Unlike website checks, there are no three consecutive failures here: what we watch for is silence.

The grace period keeps slow runs from becoming false alarms. If a backup usually takes ten minutes but sometimes takes twenty on a busy night, a 30-minute grace period saves you a 3 a.m. scare.

Common things to watch

These are typical examples, not customer stories:

• Backups. The nightly script pings when it finishes. Miss one, and you find out the next morning instead of months later.
• Data syncs. An hourly job that updates prices or stock between a store and an ERP.
• Framework schedulers. The system cron that triggers WordPress or Laravel scheduled tasks.
• Reports and exports. A daily job that sends an email or writes a file.

Heartbeats vs. website uptime checks

A website monitor answers "does my page respond?" A heartbeat answers "did my job run?" A site can be perfectly healthy while its backup hasn't run for a month, and the reverse can happen too. Most teams want both: one monitor for the site and one heartbeat for each job that matters. If writing the schedule is the hard part, the free cron expression generator builds it for you.

Limits worth knowing

• We detect silence, not the cause. The alert tells you the ping didn't arrive; your server logs tell you why.
• A ping that arrives doesn't prove the work succeeded, unless your script only pings after a clean finish.
• If your server can't reach the internet, the ping won't arrive even if the job ran.
• Checks run from a single location: our server.

Alerts and plans

Alerts go to the channels in your alert list: email on Free, and on paid plans also WhatsApp, Slack, Microsoft Teams, Discord, Telegram, or a signed webhook. The alerts page explains how each channel delivers. Monitor limits and intervals for each plan are on the pricing page.