Heartbeat Monitoring: Alerts When a Service Stops Checking In

Uptime checks can't see inside your infrastructure — a queue worker, sync daemon or backup script can die silently while your website looks perfectly healthy. Heartbeat monitoring flips the direction: your service pings a unique URL every time it runs, and the moment a ping doesn't arrive on time, you get alerted. One curl line to hook up, nothing to install.

Everything a Dead Man's Switch Should Do

Built for the invisible half of your stack — the jobs nobody notices until they've been broken for a week

One-Line Setup

Append a single curl call to your worker, script or service loop. Any HTTP method works, from any language or tool that can make a request — no agent, no SDK, no firewall holes.

Flexible Expectation Windows

Expect a ping every minute or every week — anything from 1 minute to 365 days — plus a grace period that absorbs normal runtime variance before anyone gets paged.

Exit-Code Awareness

Report the process exit code with the ping (/0, /2, /fail). A failing run alerts as “run failed” with the real code — not a misleading “missed schedule”.

Run Duration Tracking

Send start and finish pings with a shared run ID and every run's duration is measured, charted, and alertable — catch the backup that suddenly takes 4× longer.

Logs With Every Ping

POST up to 10 KB of output with each ping — the job's last log lines land right next to the event in your dashboard, so diagnosing a failed run doesn't start with SSH.

Instant, Accurate Alerts

A missed window opens an incident immediately — no waiting for multiple failures — and one successful check-in resolves it. Email, Slack, Discord, webhooks and 20+ more channels.

Healthchecks-Compatible Pings

The ping URL conventions match what your scripts may already use — migrating from Healthchecks-style endpoints is usually just swapping the domain in existing curl lines.

Full Ping History

Every check-in, start, failure and missed window in one filterable log — with exit codes, run IDs, durations and attached output — so you can see drift and lateness at a glance.

Why Heartbeat Monitoring Belongs Next to Your Uptime Checks

Active monitoring answers “is my site up?” — heartbeat monitoring answers “is my machinery actually doing its work?”. The failure mode it catches is the worst kind: silent. A dead worker throws no error page, a stopped sync writes no log, a crashed daemon triggers no 500. The only observable signal is absence, and that's exactly what a dead man's switch detects. It counts as a regular monitor on every plan, including Free — no separate per-job pricing.

Start monitoring now

Catch silent failures no uptime check can see

One curl line per service — works from cron, systemd, Kubernetes, anywhere

Grace periods tuned per job, from strict minutes to relaxed days

Exit codes turn “it didn't run” and “it ran but failed” into different alerts

Run durations measured from start/finish ping pairs

Job output stored with every ping for instant diagnosis

Incidents open on the first miss and resolve on the first check-in

Included in the normal monitor quota — Free plan included

How Heartbeat Monitoring Works

Reverse the direction: your systems report in, we watch the clock

1

Create a Heartbeat Monitor

Choose how often your service should check in — every 5 minutes, every hour, every day — and how much lateness the grace period should forgive.

2

Add the Ping to Your Service

Copy the unique ping URL from the Setup guide and call it from your worker or script whenever a cycle completes. The URL token is the only secret.

3

We Watch the Silence

Every ping re-arms your monitor's timer. As long as check-ins arrive inside the window plus grace, everything stays green — no news is good news.

4

Get Alerted on the First Miss

If the window closes without a ping, an incident opens immediately and your channels fire — with job-side diagnostics that tell you where to look first.

What Teams Watch With Heartbeats

If it should run regularly, it should check in regularly

Queue Workers & Consumers

Sidekiq, Celery, BullMQ, custom consumers — a crashed worker quietly lets the queue grow for hours. A per-cycle heartbeat catches the crash within minutes, not when customers notice delays.

Backups & Data Syncs

The classic silent failure: the nightly backup that stopped running three weeks ago. With a heartbeat on the backup script — and its output attached to each ping — you know the same morning, with the log in hand.

Daemons & Long-Running Services

Internal services without a public endpoint can't be probed from outside. A periodic self-ping from the service's main loop proves it's not just running, but actually cycling through its work.

IoT Devices & Edge Boxes

Devices behind NAT and firewalls are unreachable for active checks — but they can always ping out. A heartbeat per device tells you which unit went dark and when.

Frequently Asked Questions

Everything you need to know about heartbeat monitoring

Heartbeat monitoring (also called a dead man's switch or passive monitoring) inverts the usual direction of checks: instead of us probing your systems, your systems ping a unique URL every time they complete a cycle of work. If a ping doesn't arrive within the expected window plus a grace period, an incident opens and you're alerted. It detects failures whose only symptom is silence.

From our blog

Guides, deep-dives, and best practices from the WatchFor team

Ready to Hear Every Heartbeat?

Give the invisible half of your infrastructure a voice. Create a heartbeat monitor, paste one curl line into your service, and know within minutes — not weeks — when something stops running. Start free, no credit card required.