StatusPulse StatusPulse
← All features

Probe type · Starter+

Heartbeat (cron) probe

The one probe StatusPulse doesn't run. Your scheduled job pings a private URL on every successful run, and silence is what triggers the alert.

Why you need it

A Heartbeat probe is the inverse of every other check: instead of StatusPulse polling your service, your service pings StatusPulse on every successful run. Absence of a beat — not a failed probe — is what flips the monitor to Down. Perfect for jobs that don't expose an HTTP port to poll: nightly database backups, weekly billing runs, hourly ETL pipelines, anything that runs on a schedule.

Each probe gets its own secret token URL of the form https://heartbeat.statuspulse.com/api/heartbeat/<token>. The token is a 32-byte cryptographic random. Two schedule modes:

  • Simple interval — "expect a beat every N minutes". Default 15 minutes.
  • Cron expression — standard 5-field cron. Parsed at save time so typos are caught up front. Interpreted in UTC.

A configurable grace period (default 60 s) absorbs cron drift, clock skew, and cold-start latency before the probe flags Degraded. Failures can be reported explicitly two ways — either POST /api/heartbeat/<token>/fail or any POST with a JSON body of {"success": false}. Opt-in payload capture stores up to 4 KB of the request body so you can see what the job emitted.

Where it pays off

The right probe for any periodic job whose health is "did it run, and did it finish successfully?":

  • Nightly database backups — pg_dump finishes, curl the heartbeat URL. Missing beats wake on-call before the next morning's restore drill.
  • Billing runs / invoice generation — monthly job that absolutely must complete. Cron-expression mode pins the schedule.
  • ETL / data sync — hourly pipeline pulling from a third-party API. Failure-mode reporting gives you the upstream's status code without leaving StatusPulse.
  • GitHub Actions / GitLab CI nightly jobs — a single curl at the end of the workflow turns a green CI run into a green status-page row.
  • Kubernetes CronJob health — missed beats catch the silent-CrashLoopBackOff failure mode.

Not the right choice when: you're monitoring a long-running web service or API — use HTTP. Also a poor fit for events that don't run on a clock (a webhook receiver, a user-triggered job).

Configuration parameters

Field Type Required Default Description
Name string Required — Human-readable label for the probe. Shown in the dashboard, status page, and alert subject lines.
Schedule mode SimpleInterval | CronExpression Required SimpleInterval How the expected cadence is expressed.
Expected interval (seconds) integer Required if SimpleInterval 900 Time the probe expects between heartbeats. Default 900 s (15 min).
Cron expression string (5-field cron, UTC) Required if CronExpression — Standard 5-field cron (minute hour day month weekday). Parsed by Cronos at save time. UTC.
Grace period (seconds) integer Optional 60 How long after the expected arrival the probe waits before flagging Degraded (then Down).
Capture payload boolean Optional false When on, the receiver stores up to 4 KB of each heartbeat's request body. Off by default to avoid PII storage.
Token URL string (read-only, /api/heartbeat/<token>) Optional auto-generated 32-byte cryptographic-random URL the operator's job POSTs to. Shown in plaintext exactly once at create time + on rotate.
Paused boolean Optional false Master kill-switch.

Available on Starter+. Already on StatusPulse? See the full config in Help →

Related

Try Heartbeat (cron) probe in StatusPulse

5 probes, 1 status page, forever. No credit card. US or EU host — you choose.

Start free See pricing