Know when your service stops doing its job.
A heartbeat is a positive signal — every healthy iteration of your loop sends one outbound ping. When the pings stop arriving, the absence is the alert. Catches the queue worker that’s "running" but stuck, the daemon Kubernetes silently restarted, the sync loop that swallowed every exception.
How it works
Three steps. Less than a minute.
Create a heartbeat monitor
Set the expected interval (e.g. `5m`, `1h`, `30s`) and a grace period. Drumbeats tracks the next expected ping server-side.
Ping from your loop
One outbound HTTPS request per healthy iteration — bash, Python, Node.js, Go, Rust, anything that can `curl`. No SDK, no daemon.
Hear about silence first
A 30-second status detector flags a missed beat the moment the schedule + grace window elapses. Alerts route to Slack, Email, Telegram, Discord, browser push, or a webhook.
The actual product
Three views into a heartbeat monitor
Real components, virtual data. A 5-minute heartbeat from a worker process.
Reliability
Every expected beat, plotted against the schedule
Six hours of expected beats at 5-minute cadence. Two missed in a row, one incident. The status detector polls every 30 seconds, so a silent worker becomes a flagged incident in well under a minute past the grace period.
Live status
Silence is the alert
Each healthy iteration of your loop sends one outbound ping. Drumbeats tracks the schedule server-side and watches for that ping. The absence of a beat in the expected window — plus the configurable grace period — IS the signal.
- 1-minute resolution on Free, 30-second on Pro
- Outbound HTTPS only — works behind firewalls and inside private VPCs
- No SDK, no daemon, no shared library to vendor
- Same Beats pool covers cron, queue, and uptime monitors
Beat history
Every beat received, exportable
The dashboard table records each beat with duration, source IP, and any error message your code attached. Failures show the message inline. CSV export is the same one click as the dashboard.
Why heartbeat monitoring
A heartbeat is a positive signal — and silence is the alert
Heartbeat monitoring is the inverse of traditional uptime checks. Instead of asking "is the service still up?" from the outside, the service itself sends a periodic ping that says "I am still doing useful work." When the pings stop arriving, the absence is the alert. The trick is that this catches a category of failure that pure HTTP probing cannot: a process that is alive (TCP connections still open, the health endpoint still returns 200) but has stopped doing the thing it was supposed to do.
The pattern is well known to anyone who has tried to alert on a stuck queue worker, a frozen sync loop, a payment poller that is "running" but no longer fetching new transactions, or a Kubernetes pod that is `Ready` but quietly OOM-throttled. Prometheus can do it with `absent()` queries — but maintaining those queries across hundreds of services is its own job, and `absent()` rules silently break when label sets change. Heartbeat monitoring removes the middleware: every healthy iteration of the work loop sends a ping; every interval that passes without one fires an alert.
Drumbeats heartbeat monitors take a single configuration parameter — the expected interval (e.g. `5m` or `30s`) plus a per-monitor grace period — and watch for that ping. Anything that can make an outbound HTTPS call can ping in: bash loops, Python scripts, Go workers, Kubernetes liveness sidecars, Lambda functions, or even a curl from inside a Docker healthcheck. There is no daemon to install, no rules to deploy, no metric label to forget.
Stuck loops (the worker that "runs" but does nothing)
A poll loop that catches every exception and retries forever, a Sidekiq job stuck on a poisoned message, a Kafka consumer rebalancing endlessly. Externally everything looks fine. A heartbeat from inside the loop body fires the moment the loop stops making progress.
Daemons the supervisor restarted but never logged
`systemd` silently restarts a unit until it gives up. Kubernetes restarts a pod a few times then leaves it `CrashLoopBackOff` without paging anyone. A heartbeat that goes silent is unambiguous — neither the supervisor restart count nor the readiness probe distinguishes a working service from one that is up but inert.
Network or firewall changes that hide the problem
Your Prometheus server can’t reach the exporter, but the service itself is fine. With heartbeats the failure mode flips: the SERVICE makes the call, so a firewall change that breaks observability also breaks heartbeats — and you find out in seconds instead of finding stale dashboards weeks later.
Pair heartbeats with `/start` + `/failure` pings for the most common upgrade path — instead of just knowing whether the service is alive, you know how long each iteration took, what the exit code was, and whether the success rate is drifting.
One ping. You're done.
No SDK, no agent, no library. A single HTTP request is all it takes.
const MONITOR_ID = 'YOUR_MONITOR_ID';
const PING_URL = `https://api.drumbeats.io/v1/ping/${MONITOR_ID}`;
// Ping Drumbeats on every iteration of your recurring process
setInterval(async () => {
const isHealthy = await checkPaymentGateway();
if (isHealthy) {
await fetch(PING_URL); // heartbeat received
}
// If unhealthy, don't ping — Drumbeats detects the silence
}, 5 * 60 * 1000); // every 5 minutesWhat does it cost?
What 200K Beats actually buys you
Free includes 200,000 Beats/month. A heartbeat at 5-minute cadence uses about 8,640 Beats per monitor per month (30-day month) — Free covers ~23 of them. At 1-hour cadence, 200K Beats covers ~277 monitors (capped at 50 on Free). Need 50 workers each pinging every 5 minutes? That’s 432K Beats — Pro at $20/mo, with the same pool covering your cron and uptime monitors.
Outgrowing Free? Pro at $20/mo gets 1,000,000 Beats and 30-second intervals. Same plan covers cron, queue, and uptime monitors.
Drumbeats vs. rolling your own dead-man-switch
"Page me if X stops happening" feels trivial until you actually have to maintain it across 50 services. Here is what each approach costs in production.
FAQ
Common questions
Is your worker still actually working?
Heartbeat monitoring is the dead-man-switch for your services. If the next ping doesn’t arrive within the schedule + grace window, you find out in under a minute — not when the queue depth chart goes vertical.
No credit card required · 50 monitors free · Setup in 60 seconds
Keep exploring
What to read next
Related monitoring
- Cron job monitoring
Same heartbeat model anchored to a cron expression instead of an interval.
- Background job monitoring
Per-run lifecycle tracking for async tasks (start + success/failure pairs).
- Queue worker monitoring
Sidekiq, Celery, BullMQ, RQ — heartbeat from inside the worker loop.
- Incidents & alerts
Routing, escalation, and acknowledgement workflows for heartbeat failures.
Free tools
- AI agent setup
Generate a paste-ready Cursor / Claude Code / Codex prompt that wires heartbeats automatically.
- Cron expression generator
Useful when you want a heartbeat with a non-uniform cadence.
- Website down checker
One-shot HTTP check — the inverse-of-heartbeats sanity test.
Resources
- Drumbeats vs. Healthchecks.io
Two heartbeat-monitoring tools compared on price and feature depth.
- Why we built Drumbeats
The category context behind heartbeat-style monitoring at modern scale.
- Pricing & Beats explainer
Calculate Beat usage for your specific heartbeat intervals.
- Full FAQ
49 deeper technical answers including run_id, payloads, and edge cases.