Cron job monitoring that alerts you when a scheduled job silently stops

How heartbeat monitoring works

Heartbeat monitoring flips the usual direction of a check: instead of Uptime Tracker calling your server, your job calls Uptime Tracker each time it finishes successfully. Silence is the signal. If no call arrives within the expected interval plus the grace period, the job is considered missed, an incident opens, and alerts go to your channels.

This catches the failures that ordinary uptime checks cannot see:

• The cron daemon stopped, or the crontab was overwritten during a deploy.
• The job crashed, hung, or ran out of memory before finishing.
• A queue worker is running but no longer processing work.
• A server was decommissioned and its scheduled tasks went with it.

Each heartbeat monitor has its own secret URL. Your job can call it with GET or POST. Up to 10 signals per minute are accepted per heartbeat, which is plenty for jobs running every 15 seconds.

Uptime Tracker heartbeats accept success pings only; there are no separate start or failure signals. The simplest way to report failure is to only send the ping when the job succeeds, which is exactly what && does in a shell. A failed job then looks the same as a job that never ran, and you are alerted either way.

Which jobs can you monitor? The 15-second to 1-hour range

Heartbeat monitors in Uptime Tracker accept an expected interval from 15 seconds to 1 hour, so they fit frequent jobs and hourly tasks but not daily or weekly schedules. Being clear about this up front saves you from setting up a monitor that cannot match your job.

The grace period, from 0 to 60 minutes with a default of 5, absorbs jobs whose run time varies. An hourly job that sometimes takes 20 minutes should have a grace period of at least 20 minutes, so a slow run does not count as missed. The longest possible window between pings is therefore 1 hour plus 60 minutes of grace.

For a daily job, one workable pattern is to add a small hourly companion task that checks the job's last successful output (for example the age of the newest backup file) and pings the heartbeat only if it is recent enough. That way the heartbeat stays within the supported range while still telling you when the daily job fails.

Add a heartbeat to your job

Adding cron job monitoring takes one command appended to the job, and it works from any language or scheduler that can make an HTTP request.

1. Create a heartbeat monitor and set the expected interval to match the job's schedule.
2. Set the grace period to cover the longest normal run time.
3. Copy the monitor's secret URL.
4. Call the URL at the end of the job, only when it succeeds.
5. Run the job once by hand and confirm the monitor shows the first ping.

A crontab entry that runs every 15 minutes looks like this:

*/15 * * * * /usr/local/bin/sync-orders.sh && curl -fsS https://uptimetracker.live/api/v1/heartbeats/<token> > /dev/null

The -f flag makes curl treat HTTP errors as failures, -sS keeps it quiet unless something goes wrong, and && means the ping is only sent if the script exits successfully.

The same idea works elsewhere: a final step in a systemd timer unit, a Kubernetes CronJob container that runs curl after the main command, a scheduled CI pipeline, or an HTTP call at the end of a Python, Node or Go worker loop. Treat the URL like a password; anyone who has it can send pings. More examples are in the help center.

Monitoring internal services and homelabs with heartbeats

Heartbeats are the way to monitor anything Uptime Tracker cannot reach directly, because the check runs inside your network and only makes an outbound HTTPS request. Standard monitors cannot target private or internal network addresses, which protects the platform from being used to probe internal networks. Heartbeats fill that gap.

Common examples:

• NAS and backup boxes: ping after each successful snapshot or sync.
• Home servers and Raspberry Pis: a cron job that checks a local service and pings only if it responds.
• Internal APIs and databases: a small script on an internal host runs a health query and pings on success.
• Office network: a device that pings every few minutes tells you when the site's internet connection drops, because the heartbeats stop.

Because no inbound port needs to be opened, there is nothing to configure on your router or firewall. That also makes heartbeats a good fit for sites behind NAT or carrier-grade NAT.

Homelab users often route these alerts to Telegram or Discord on the Free plan, or to ntfy, Gotify or Pushover on Starter. See uptime monitoring for personal projects and homelabs for a complete setup.

Alerts, incidents and maintenance for missed jobs

A missed heartbeat is treated like any other outage: an incident opens, alerts go to the channels you choose, and the incident resolves automatically when pings resume. You can acknowledge, assign and annotate it just like a website outage.

Alert routing matters for jobs because not every missed run is urgent. On Starter and Team you can create routing rules by tag or monitor, so a missed billing job goes to SMS while a missed analytics export only posts to a Slack channel. Repeat reminders keep notifying until someone acknowledges the incident or the job recovers. On Team, escalation policies and on-call rotations make sure a critical job failure reaches whoever is on call. See alerts and notifications for every channel.

When you deliberately stop jobs, such as during a server migration, schedule a maintenance window. Alerts are suppressed during the window, and it is excluded from availability. One-off windows are available on every plan; recurring weekly windows, useful for a fixed weekly patch night, require Starter or Team.

Heartbeat monitors can also appear as components on a status page, for example a "Background processing" component that customers can check when exports or emails seem delayed.

What's included on each plan

Heartbeat monitors are included on every plan and are counted separately from standard monitors, so adding cron job monitoring does not use up your website checks.

The Free plan alone gives you 5 heartbeats plus 2 standard monitors, which is enough to cover the backup, sync and cleanup jobs of a small project and the site they support. Starter suits teams with more scheduled work or jobs that need to page someone by SMS, and Team suits environments with many workers and an on-call rotation.

The interval range and grace period are the same on every plan, so you never have to upgrade just to monitor a faster job. See the pricing page for every limit.