Heartbeat watchdog for jobs that go quiet
A heartbeat watchdog expects a periodic check-in. Miss the window and you get alerted—before customers notice the silence.
The monitor-dies-unnoticed problem
The worst failures are quiet: the worker is gone, the queue is stuck, or the watcher itself stopped. Nothing turns red because the thing that would turn red is offline too.
How a heartbeat watchdog works
Your job periodically POSTs a heartbeat with a secret token. The watchdog tracks last-seen time. If last-seen ages past your timeout, it fires an alert. Recovery heartbeats clear the timeout state so you are not spammed forever.
Bearer token heartbeats (curl / cron)
curl -X POST \ -H "Authorization: Bearer <token>" \ https://pulseguard.agentbuff.dev/api/heartbeat
See docs for cron examples and auth details.
Timeout threshold & alert path
Set timeout ≥ interval. Alerts go to Telegram in the trial. Probe creation is blocked until an alert channel is configured, so you cannot silently “arm” a watchdog with nowhere to shout.
Good fit / poor fit
Good fit: cron, batch jobs, always-on workers, a secondary check that your primary monitor can still “pet” the switch. Poor fit: replacing full APM, multi-region status pages, or complex on-call routing—PulseGuard stays thin on purpose.
FAQ
What is a heartbeat watchdog?
A heartbeat watchdog expects periodic pings from your jobs. Miss the window and you get alerted that the process went quiet.
How do heartbeats work with cron?
Your cron (or worker) POSTs an authenticated heartbeat on each successful run. PulseGuard tracks the last check-in and alerts if it goes stale.
Why Telegram?
Telegram is a fast path for the MVP trial: configure a chat once and get mobile-friendly alerts when heartbeats stop.
Is this the same as site uptime monitoring?
No. Uptime probes your site. A heartbeat watchdog waits for your jobs to report in. PulseGuard Watchdog is built for the second case.