tutorial

Heartbeat Monitoring and Cron Job Monitoring Explained (2026 Guide)

Your database backup runs every night at 2 AM. Your ETL pipeline processes new data every hour. Your invoice generation job fires on the first of every month...

Your database backup runs every night at 2 AM. Your ETL pipeline processes new data every hour. Your invoice generation job fires on the first of every month. Each of these jobs completes in silence — or fails in silence.

Without heartbeat monitoring, the only way you discover a failed cron job is when someone notices the consequences: stale data, missing invoices, an unrestored database backup three weeks after the server failure that was supposed to be covered. By then, the damage is done.

Heartbeat monitoring is the solution. This guide explains what it is, why it matters, and how to set it up.

What Is Heartbeat Monitoring?

A heartbeat monitor is a check that expects to receive a signal periodically. Instead of your monitoring service reaching out to check your endpoint (the "ping-out" model), heartbeat monitoring works in reverse: your job reaches in to signal that it completed (the "ping-in" model).

The analogy is a heartbeat in the medical sense. A cardiac monitor does not send an electrical pulse to the heart — it listens for the heart's own pulse. If the expected pulse stops arriving, the alarm triggers.

In software monitoring:

  1. Your monitoring service creates a heartbeat monitor with a configured expected interval (e.g., every 60 minutes)
  2. Your cron job or scheduled task is instrumented to send an HTTP request to a unique heartbeat URL when it finishes
  3. The monitoring service waits. If the ping is not received within the expected window, it fires an alert

The absence of a signal is the alert condition. This is fundamentally different from HTTP uptime monitoring, where the monitoring service probes your endpoint and alerts on a failed response. Heartbeat monitoring alerts on silence — on a job that should have spoken and did not.

Why Cron Job Silence Is Dangerous

Scheduled tasks fail in ways that are uniquely invisible:

Silent exit codes: A script runs, encounters an error, logs the stack trace to a file no one reads, and exits with a non-zero code. The cron daemon considers this "ran" — it did run, it just did not succeed. Without a heartbeat check, nothing alerts.

Lock file issues: A cron job tries to acquire a lock, finds it held by a previous stuck run, and exits immediately without doing any work. No error, no alert.

Environment differences: A job runs fine interactively but fails under the cron environment due to missing PATH variables or undefined secrets. The cron daemon schedules it again next interval. It silently fails again.

Partial completion: An ETL pipeline processes 80% of records before hitting a network timeout. It exits cleanly, but 20% of your data is stale. Uptime monitoring cannot detect this. Heartbeat monitoring catches it if the final checkpoint is instrumented correctly.

Dependency failures: A backup script depends on S3 credentials. The credentials rotate and are not updated. The backup script fails silently. Three weeks later, disaster recovery is attempted against a three-week-old backup.

These scenarios share a common pattern: the infrastructure looks healthy, the server is running, the cron daemon is functioning, but the work is not being done. No infrastructure monitoring tool catches this. Heartbeat monitoring was designed specifically for this failure class.

How Heartbeat Checks Work

The mechanics are straightforward:

  1. Create a heartbeat monitor in your monitoring tool. Specify the expected signal interval — how often the job is supposed to run. Vigilmon supports intervals from 1 minute to 24 hours.

  2. Instrument your job to send an HTTP GET or POST request to the heartbeat URL after successful completion.

  3. The monitoring service tracks receipt. If the expected interval passes without a ping, it fires a configured alert (Slack, email, webhook).

A typical heartbeat URL looks like:

https://vigilmon.online/heartbeat/abc123xyz

Your cron job hits that URL on completion. If the monitoring service does not see a ping within the configured grace period after the expected interval, the alert fires.

Heartbeat Monitoring Use Cases

Database Backups

Database backups are the canonical heartbeat use case. A backup that does not run is worse than no backup strategy at all — it creates false confidence. Instrument your backup script to ping the heartbeat URL after the archive is written and verified:

#!/bin/bash
# nightly-backup.sh

pg_dump -Fc mydb > /backups/mydb-$(date +%Y%m%d).dump

if [ $? -eq 0 ]; then
  curl -s "https://vigilmon.online/heartbeat/YOUR_HEARTBEAT_ID" > /dev/null
fi

If the heartbeat ping is not received, the backup either failed or did not run. Either way, the alert fires and the on-call engineer investigates before a disaster scenario makes the missing backup critical.

ETL Pipelines

Data pipelines that run on a schedule should signal completion at each meaningful checkpoint:

import requests

def run_etl_pipeline():
    extract_data()
    transform_data()
    load_to_warehouse()
    
    # Only ping on full success
    requests.get("https://vigilmon.online/heartbeat/YOUR_HEARTBEAT_ID", timeout=5)

if __name__ == "__main__":
    run_etl_pipeline()

Signal only on successful completion. If any stage fails, the exception propagates, the heartbeat URL is never hit, and the monitoring service alerts.

Invoice and Billing Jobs

Billing jobs that fail silently mean customers are not charged, or charged incorrectly, sometimes for extended periods before anyone notices. Heartbeat monitoring catches the silence immediately:

// billing-job.js
async function runBillingCycle() {
  await processSubscriptions();
  await generateInvoices();
  await sendInvoiceEmails();
  
  // Notify heartbeat monitor on success
  await fetch('https://vigilmon.online/heartbeat/YOUR_HEARTBEAT_ID');
}

Certificate Renewal Jobs

Automated certificate renewal (e.g., Let's Encrypt via Certbot) can fail silently. A renewal job that stops running means your certificates expire and your HTTPS sites go dark. Instrumenting the renewal job with a heartbeat check gives you advance warning before expiry — not a page when the cert is already expired.

Scheduled Reports

Report generation jobs that feed dashboards, send weekly summaries, or export compliance data should be monitored. A silent failure here often goes undiscovered until a stakeholder mentions they have not seen the weekly numbers in three weeks.

Setting Up Heartbeat Monitoring with Vigilmon

  1. Log in to vigilmon.online and navigate to Add Monitor.

  2. Select Heartbeat as the monitor type.

  3. Configure the interval — how often your job is expected to run. Set a grace period to allow for normal variance in runtime.

  4. Copy your heartbeat URL — a unique URL generated for this monitor.

  5. Instrument your job — add a curl, wget, or HTTP call to the heartbeat URL at the end of your script, inside a success condition.

  6. Configure alerts — select your alert channel (Slack, email, webhook) and who to notify when the heartbeat goes silent.

The heartbeat monitor appears on your Vigilmon dashboard alongside HTTP, TCP, and SSL monitors. Your status page reflects its state. If the job runs successfully, the monitor stays green. If the job goes silent, the monitor turns red, the alert fires, and your team investigates before the consequences compound.

Heartbeat vs. Uptime Monitoring: Complementary, Not Redundant

Uptime monitoring checks whether your endpoints are reachable. Heartbeat monitoring checks whether your jobs are completing. These monitor different failure surfaces:

| Failure type | Uptime monitoring detects | Heartbeat monitoring detects | |---|---|---| | API endpoint is down | Yes | No | | Cron job failed silently | No | Yes | | Server is unreachable | Yes | No (timeout looks like silence) | | Backup did not complete | No | Yes | | Database port closed | Yes (TCP monitor) | No | | ETL pipeline partially ran | No | Yes (if checkpointed correctly) |

A complete monitoring posture includes both. HTTP/TCP/SSL uptime monitoring covers the "can users reach us?" surface. Heartbeat monitoring covers the "are our scheduled processes completing?" surface.

Conclusion

Silent failures are the hardest to catch and often the most consequential. A failed backup discovered only during disaster recovery, a billing job that silently stopped three weeks ago, an ETL pipeline that has been running but not completing — these are failures that look like success until they are not.

Heartbeat monitoring flips the detection model: instead of checking that something is up, it listens for a scheduled process to report that it completed. Silence is the alarm.

Start monitoring your cron jobs and scheduled tasks for free at vigilmon.online — heartbeat monitoring with configurable intervals and grace periods, alongside HTTP, TCP, and SSL monitors. No credit card required.

Tags: #monitoring #devops #cron #heartbeat #sre #scheduler #backend

Monitor your app with Vigilmon

Free plan — 5 monitors, no credit card required. Up and running in 60 seconds.

Start free →
← Back to all articles