Heartbeat monitoring

Uptime monitoring answers "is my site up?" Heartbeat monitoring answers a harder question: "did my backup actually run last night?" Cron jobs, scheduled tasks, ETL pipelines, and queue workers fail silently — the server stays up, the site keeps responding, and nothing anywhere reports that the 3 AM database backup hasn't completed in eleven days.

That failure mode is invisible to conventional monitoring because there is nothing to probe. A dead cron job doesn't return a 500; it simply produces no output at all. The only reliable way to catch it is a dead man's switch: the job must actively prove it ran, and silence becomes the alert.

FourSight's heartbeat monitors do exactly that, alongside the seven other check types on the same dashboard, the same escalation policies, and the same status pages — so your scheduled jobs are monitored with the same rigor as your public endpoints.

When you create a heartbeat monitor, FourSight generates a unique, unguessable ping URL for that job. You add one line to the end of the job — a curl call, an Invoke-RestMethod, a fetch — so the job reports in every time it finishes successfully. FourSight records each ping with its timestamp, source IP, and user agent, giving you a verifiable log of every run.

Three settings define what counts as a failure. The expected interval is how often the job should run — every 5 minutes, hourly, nightly. The grace period is slack added on top, so a job that finishes 40 seconds late on a nightly schedule doesn't page anyone (the default is 60 seconds; tune it to your job's worst-case runtime). The miss threshold is how many consecutive expected pings can be missed before an incident opens — 1 for critical jobs, 2 or more for jobs with naturally variable runtimes.

For jobs that don't run on a fixed interval, FourSight supports cron expression scheduling: give the monitor the same cron expression as the job itself (for example 0 3 * * *) and it computes exactly when each ping is due, applying the grace period around each expected run rather than a rolling interval.

Heartbeat monitor settings

Setting	What it controls	Default
Expected interval	How often the job should ping (interval mode)	5 minutes
Cron expression	Exact schedule for cron-mode monitors (e.g. 0 3 * * *)	—
Grace period	Extra time allowed after a ping is due before it counts as missed	60 seconds
Miss threshold	Consecutive missed pings before an incident opens	1

One line, appended to the job. The && in the crontab example matters: the ping only fires when the job exits successfully, so a crashing script is treated exactly like a script that never ran — which is what you want.

Tip: GitHub Actions scheduled workflows are silently disabled after 60 days of repository inactivity — a heartbeat monitor is the only way to find out before it matters.

Anything that's supposed to happen on a schedule and would hurt if it quietly stopped. The common thread: none of these have a URL you could point an uptime check at.

Honestly: Cronitor and Healthchecks.io are both excellent, purpose-built cron monitors. Cronitor adds job telemetry and performance metrics; Healthchecks.io is open source, self-hostable, and has one of the most generous free tiers in the category. If heartbeats are the only thing you need, either is a fine choice.

The case for FourSight is consolidation. Cron monitoring is rarely the whole job — the same team also needs uptime checks, SSL expiry, DNS drift, port checks, and a public status page, and running a dedicated cron monitor alongside a separate uptime monitor means two dashboards, two alert configurations, two invoices, and two places incidents can hide. FourSight's Growth plan puts heartbeats next to the other seven check types under one escalation policy for a flat $40/mo.

FourSight vs dedicated cron monitors

Capability	FourSight	Cronitor	Healthchecks.io
Heartbeat / cron monitoring	Yes (Growth plan and above)	Yes — core product	Yes — core product
Cron expression schedules	Yes	Yes	Yes
Full uptime monitoring (HTTP, SSL, DNS, domain, port, keyword, ping)	Yes — 8 check types included	Uptime checks available; narrower type coverage	No — heartbeats only
Multi-region confirmation before alerting	4-region quorum	No equivalent	No equivalent
Public status pages	Included on every plan	Available on paid plans	Not included
Self-host option	No	No	Yes — open source
Job telemetry / runtime metrics	Ping log with timestamp, source IP & payload	Yes — richer job metrics	Basic ping log

Because incidents don't respect tool boundaries. When a database server degrades, the symptom often shows up in three places at once: the API slows down (HTTP check), the backup job overruns its window (heartbeat), and the replica port stops accepting connections (port check). If those three signals live in three tools, you triage three alert streams and correlate by hand at 3 AM. In one tool, they're one incident timeline.

Consolidation also fixes the quieter problem of coverage decay. Standalone cron monitors are set up by one engineer and forgotten; when they leave, the account lapses and nobody notices — the monitoring equivalent of the silent cron failure it was meant to catch. Keeping heartbeats inside the platform your team already uses for uptime keeps them visible, reviewed, and owned.

Included in Growth — $40/mo flat

Monitor your first cron job in five minutes

Heartbeat monitors are included in the Growth plan alongside all eight check types, 100 monitors, 30-second intervals, escalation policies, and five status pages — one flat price, no per-monitor fees.

• Unique ping URL per job — one line of shell to integrate
• Interval or cron-expression schedules with a configurable grace period
• Ping log with timestamp, source IP, and payload as run evidence
• Same escalation policies and status pages as your uptime checks

FAQ