---
title: "Heartbeat Monitoring for Cron Jobs &amp; Scheduled Tasks | FourSight"
description: "Ensure your cron jobs, background workers, and scheduled tasks run on time — get alerted the moment a job goes silent."
lang: en
json-ld: |
  [
    {
      "@context": "https://schema.org",
      "@type": "Article",
      "headline": "Heartbeat Monitoring for Cron Jobs & Scheduled Tasks",
      "description": "Ensure your cron jobs, background workers, and scheduled tasks run on time — get alerted the moment a job goes silent.",
      "author": {
        "@type": "Organization",
        "name": "FourSight"
      },
      "publisher": {
        "@type": "Organization",
        "name": "FourSight"
      },
      "url": "https://foursight.cloud/guides/heartbeat-monitoring-cron-jobs",
      "mainEntityOfPage": "https://foursight.cloud/guides/heartbeat-monitoring-cron-jobs",
      "datePublished": "2025-10-01",
      "dateModified": "2026-07-09",
      "wordCount": 2200
    },
    {
      "@context": "https://schema.org",
      "@type": "BreadcrumbList",
      "itemListElement": [
        {
          "@type": "ListItem",
          "position": 1,
          "name": "Home",
          "item": "https://foursight.cloud"
        },
        {
          "@type": "ListItem",
          "position": 2,
          "name": "Guides",
          "item": "https://foursight.cloud/guides"
        },
        {
          "@type": "ListItem",
          "position": 3,
          "name": "Heartbeat Monitoring for Cron Jobs & Scheduled Tasks",
          "item": "https://foursight.cloud/guides/heartbeat-monitoring-cron-jobs"
        }
      ]
    },
    {
      "@context": "https://schema.org",
      "@type": "FAQPage",
      "mainEntity": [
        {
          "@type": "Question",
          "name": "What is a dead-man's switch in monitoring?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "A monitoring pattern where a system must actively and repeatedly prove it's alive — and silence is treated as failure. Your cron job pings a unique URL on every successful run; if the ping doesn't arrive within the expected window plus a grace period, an incident opens automatically. It's the inverse of polling, and it's the only way to detect jobs that silently stopped running."
          }
        },
        {
          "@type": "Question",
          "name": "Which FourSight plan includes heartbeat monitoring?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "Heartbeat/cron monitors are included in Growth ($40/mo, 100 monitors) and above, alongside all 8 check types. The Free and Starter plans cover HTTP and ping monitors. Each heartbeat counts as one monitor against your plan's limit."
          }
        },
        {
          "@type": "Question",
          "name": "Should my job ping at the start or the end of its run?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "At the end, after your success criteria are met — otherwise you're only monitoring that the job launched, not that it worked. For very long jobs (multi-hour migrations, large backups), use two heartbeat monitors: a start ping and a completion ping, so you can tell 'never started' apart from 'started but hung.'"
          }
        },
        {
          "@type": "Question",
          "name": "How do I stop a slow-but-healthy job from triggering false alerts?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "Tune the grace period to your worst observed runtime plus about 50%, and use the miss threshold to require two consecutive missed pings for jobs with naturally high variance (like month-end batch runs). This keeps occasional slow runs quiet while a genuinely dead job still alerts on a predictable deadline."
          }
        },
        {
          "@type": "Question",
          "name": "What happens if my monitoring provider's ping endpoint is briefly unreachable?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "Use curl's --retry 3 flag (or an equivalent retry in code) so a transient network blip on either side doesn't look like a missed run. Combined with a sensible grace period, a single failed ping attempt almost never produces a false alert — the job retries, the ping lands late but inside the window."
          }
        }
      ]
    }
  ]
---

[FourSight ](/)

[Features](/#features)[Pricing](/pricing)[Guides](/guides)[Glossary](/glossary)[FAQ](/faq)

[Login](/auth)[Start free](/auth?signup=true)

[Start free](/auth?signup=true)

[All Guides](/guides)

Reliability & Infrastructure

# Heartbeat Monitoring for Cron Jobs & Scheduled Tasks

Ensure your cron jobs, background workers, and scheduled tasks run on time — get alerted the moment a job goes silent.

11 min read Guide Published Oct 1, 2025Updated Jul 9, 2026 

## Why Traditional Monitoring Can't Watch Cron Jobs

HTTP monitors poll your servers from the outside, but cron jobs, queue workers, and scheduled tasks run inside your infrastructure with no public endpoint. If a nightly billing reconciliation silently stops running, an HTTP check will never notice. Heartbeat monitoring flips the model: your job pings FourSight when it completes, and FourSight alerts you when the ping doesn't arrive on time.

**💡** According to incident post-mortems, over 40% of silent SaaS outages originate from background jobs that stopped running without anyone noticing for hours — or days.

## A Dead-Man's Switch for Your Infrastructure

The mental model that makes heartbeat monitoring click is the [dead-man's switch](/glossary/heartbeat-monitor "Glossary: dead-man's switch"): the safety mechanism on a train that requires the driver to keep applying pressure — the moment the pressure stops, the brakes engage automatically. Heartbeat monitoring applies the same inversion to your jobs. Instead of asking 'can I reach the server?' (which says nothing about whether last night's backup ran), the system demands continuous proof of life: your job must actively report success, on schedule, forever. Silence is treated as failure. This inversion is what catches the failure modes ordinary monitoring can't: the crontab line deleted in a bad deploy, the server that was decommissioned while its jobs quietly moved nowhere, the scheduler daemon that stopped after a reboot, the job that runs but exits early before doing its work. In every one of those cases nothing is 'down' — there's simply an absence where work should be. A dead-man's switch is the only monitor that hears absence.

## How Heartbeat Monitoring Works

When you create a heartbeat monitor in FourSight you receive a unique ping URL. Your job sends a simple HTTP request to that URL every time it completes successfully. FourSight tracks the expected interval and a configurable grace period. If a ping doesn't arrive before the deadline, FourSight opens an incident and notifies your team through your configured [escalation policy](/glossary/escalation-policy "Glossary: escalation policy").

### Fixed-Interval Mode

Set an expected interval (e.g. every 5 minutes, every hour) and a grace window. This is ideal for jobs that run on simple repeating schedules like queue consumers, health-check scripts, or data-sync workers.

### Cron-Expression Mode

Provide a standard 5-field cron expression (e.g. '30 2 \* \* \*' for 2:30 AM daily). FourSight calculates the next expected run time dynamically, making it perfect for jobs with complex schedules like 'every weekday at 9 AM' or 'first Sunday of the month'.

### Grace Period & Miss Threshold

The grace period absorbs normal jitter — a job that's 20 seconds late on a 5-minute schedule shouldn't wake anyone up. The miss threshold lets you require multiple consecutive missed pings before alerting, reducing noise from transient issues.

## Setting Up Your First Heartbeat Monitor

In the FourSight dashboard, create a new monitor and select the Heartbeat type. Choose your schedule mode, set your interval or cron expression, and configure a sensible grace period. FourSight generates a unique ping URL you'll add to the end of your job.

**💡** The && operator matters: the ping only fires if the backup script exits 0. A failing job produces silence, and silence is what triggers the alert. Heartbeat monitors are included in FourSight's Growth plan ($40/mo) and above, alongside the other 7 check types.

```
# At the end of your cron job script:
curl -fsS --retry 3 https://ping.foursight.cloud/hb/<YOUR_TOKEN>

# Example crontab entry — daily DB backup at 3 AM
0 3 * * * /opt/scripts/backup-db.sh && curl -fsS --retry 3 https://ping.foursight.cloud/hb/<YOUR_TOKEN>
```

## Copy-Paste: PowerShell & Windows Task Scheduler

Windows scheduled tasks fail even more silently than cron — Task Scheduler will happily report 'The operation completed successfully' about launching a script that then crashed. Put the ping at the end of the script itself, inside your error handling, so it only fires when the work actually finished.

```
# end of your scheduled .ps1 script — ping only on success
try {
    # ... your script logic ...

    Invoke-RestMethod -Uri "https://ping.foursight.cloud/hb/<YOUR_TOKEN>" `
        -Method Get -TimeoutSec 10 | Out-Null
} catch {
    Write-Error "Job failed: $_"
    exit 1   # no ping fires -> FourSight alerts on the missed heartbeat
}
```

### Monitoring a Commercial SaaS?

FourSight's free plan includes 10 commercial-safe monitors with multi-region validation — free forever, no card.

[Start Monitoring Free](/auth?signup=true)

## Copy-Paste: GitHub Actions Scheduled Workflows

GitHub Actions cron workflows have a notorious silent-failure mode: scheduled workflows are automatically disabled after 60 days of repository inactivity, and schedules can be delayed or skipped during high-load periods. GitHub emails you about some failures — but never about a workflow that simply stopped being scheduled. A heartbeat ping as the final step catches both.

**💡** Store the ping URL token as a repository secret rather than committing it — anyone with the URL can fake a healthy heartbeat.

```
name: nightly-job
on:
  schedule:
    - cron: "0 3 * * *"   # 03:00 UTC daily

jobs:
  run:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Do the actual work
        run: ./scripts/nightly-job.sh
      # Runs only if every previous step succeeded
      - name: Report heartbeat to FourSight
        run: curl -fsS --retry 3 "https://ping.foursight.cloud/hb/${{ secrets.FOURSIGHT_HEARTBEAT_TOKEN }}"
```

## Copy-Paste: node-cron and In-Process Schedulers

In-process schedulers like node-cron, node-schedule, or APScheduler add an extra failure layer: the schedule dies whenever the host process does. A crashed Node service takes every scheduled task with it, and nothing external knows those jobs existed. The heartbeat covers both the job logic and the process hosting it.

```
import cron from "node-cron";

// Every hour at :05 — sync exchange rates
cron.schedule("5 * * * *", async () => {
  try {
    await syncExchangeRates();

    // Ping only after the work succeeded
    await fetch("https://ping.foursight.cloud/hb/<YOUR_TOKEN>", {
      signal: AbortSignal.timeout(10_000),
    });
  } catch (err) {
    console.error("sync failed:", err);
    // no ping -> missed heartbeat -> alert
  }
});
```

## How Do You Tune the Grace Period?

The grace period is the slack between a job's expected check-in and the moment FourSight declares it missing. Too tight and normal runtime variance pages you for nothing; too loose and a genuinely dead job goes unreported for hours. Two rules cover most cases. For frequent jobs (every 1–15 minutes), set the grace period to roughly 20–50% of the interval — enough to absorb scheduler jitter and a slow network call. For infrequent jobs (hourly to daily), size the grace period from the job's runtime instead: worst-observed runtime plus 50%, because a nightly warehouse refresh that takes 12 minutes on a normal Monday may take 45 at month-end. If you're pinging at the end of the job (recommended), remember the deadline is schedule time + runtime + grace — budget for all three.

**💡** Start stricter than feels comfortable, then loosen based on real misses. A grace period you had to widen twice is calibrated; one you guessed generously on day one is a blind spot.

Job schedule

Typical runtime

Suggested grace period

Reasoning

Every 5 min (queue worker)

Seconds

1–2 min

Absorb jitter; still alert within minutes

Hourly sync

1–5 min

10–15 min

Runtime variance + one slow run

Nightly backup, 3 AM

10–45 min

60 min

Worst-case runtime + 50%

Weekly report, Mon 6 AM

~10 min

2–3 hours

Infrequent job — favor certainty over speed

Month-end billing run

Varies widely

Worst case + 50%

Consider a 2-miss threshold too

## Common Use Cases

Heartbeat monitoring is useful anywhere a process should run on a predictable schedule.

### Database Backups

Append a ping to your pg\_dump or mysqldump script. If tonight's backup doesn't complete, you'll know by morning — not during the next disaster recovery drill.

### Queue Workers & Consumers

Have your worker ping FourSight on each processing cycle. If the worker crashes or the queue stalls, the missed heartbeat triggers an alert before messages pile up.

### Billing & Invoice Generation

Scheduled billing runs are revenue-critical. A missed invoice cycle can cascade into payment failures and churn. Heartbeat monitoring catches the silence.

### Data Sync & ETL

Nightly data imports, warehouse refreshes, and third-party API syncs all benefit from heartbeat checks that confirm successful completion.

## Best Practices

Place the ping call after your job's success criteria, not at the start — a ping that fires before the work happens monitors your scheduler, not your job. Use --retry flags on curl (or explicit timeouts in code) so a transient network blip doesn't register as a dead job. Treat ping URLs as secrets: anyone holding one can fake a healthy heartbeat, so keep tokens in environment variables or secret stores, not in committed code. For long jobs, consider two monitors — one pinged at start, one at completion — to distinguish 'never started' from 'started but hung.' And pair every revenue-critical heartbeat with an escalation policy so a missed 3 AM backup pages the on-call engineer instead of sitting unread in a Slack channel.

[Create Your First Heartbeat Monitor →](/auth?signup=true)

Related Reading

-   [→ Monitoring PowerShell & Bash scripts with heartbeats](/guides/monitoring-powershell-scripts)
-   [→ Heartbeat monitoring for webhooks & ETL pipelines](/guides/heartbeat-monitoring-webhooks-etl)
-   [→ Alerting without alert fatigue](/guides/alerting-without-alert-fatigue)

## Frequently Asked Questions

### What is a dead-man's switch in monitoring?

### Which FourSight plan includes heartbeat monitoring?

### Should my job ping at the start or the end of its run?

### How do I stop a slow-but-healthy job from triggering false alerts?

### What happens if my monitoring provider's ping endpoint is briefly unreachable?

#### Related Guides

[What Is Uptime Monitoring? The Complete Guide 12 min ](/guides/what-is-uptime-monitoring)[Multi-Region Monitoring Explained 8 min ](/guides/multi-region-monitoring-explained)[SSL Certificate Expiry Monitoring 10 min ](/guides/ssl-certificate-expiry-monitoring)[How SSL Certificates Expire Silently: The Failure Modes 8 min ](/guides/how-ssl-certificates-expire-silently)

#### Compare FourSight

[vs UptimeRobot →](/compare/uptimerobot-alternative)[vs StatusCake →](/compare/statuscake-alternative)[vs Pingdom →](/compare/pingdom-alternative)

10 free commercial-safe monitors

[View Pricing](/pricing)

## Protect Your SaaS Revenue

Start monitoring in under 60 seconds.

[Start Monitoring Free](/auth?signup=true)[View Pricing](/pricing)

FourSight 

© 2026 [TetraCore](https://tetracorehq.com/). All rights reserved.

FourSight is a TetraCore product — Bowling Green, Ohio.

Product

[Pricing](/pricing)[Guides](/guides)[Glossary](/glossary)[FAQ](/faq)[About](/about)[For Agencies](/solutions/agencies)[For Startups](/solutions/startups)[Privacy](/privacy)[Terms](/terms)

Features

[Cron Job & Heartbeat Monitoring](/features/cron-job-monitoring)[SSL Certificate Monitoring](/features/ssl-monitoring)[Status Pages](/features/status-pages)[Domain Expiry Monitoring](/features/domain-expiry-monitoring)[DNS Monitoring](/features/dns-monitoring)[Port Monitoring](/features/port-monitoring)

Compare

[All comparisons](/compare)[vs UptimeRobot](/compare/uptimerobot-alternative)[vs StatusCake](/compare/statuscake-alternative)[vs Freshping](/compare/freshping-alternative)[vs Pingdom](/compare/pingdom-alternative)[vs Pulsetic](/compare/pulsetic-alternative)[vs Better Stack](/compare/better-stack-alternative)[vs Uptime Kuma](/compare/uptime-kuma-alternative)[vs Cronitor](/compare/cronitor-alternative)[vs Healthchecks.io](/compare/healthchecks-alternative)[vs Hyperping](/compare/hyperping-alternative)

Pricing Guides

[UptimeRobot Pricing](/compare/uptimerobot-pricing)[StatusCake Pricing](/compare/statuscake-pricing)[Pingdom Pricing](/compare/pingdom-pricing)[Better Stack Pricing](/compare/better-stack-pricing)[Uptime Kuma Pricing](/compare/uptime-kuma-pricing)[Cronitor Pricing](/compare/cronitor-pricing)[Healthchecks.io Pricing](/compare/healthchecks-pricing)[Hyperping Pricing](/compare/hyperping-pricing)[Pulsetic Pricing](/compare/pulsetic-pricing)