Heartbeat and cron job monitoring
Silent scheduled jobs are the failures nothing catches. They do not throw an error, so error tracking stays quiet and uptime tools stay green. PulseStack heartbeats flip that on its head: your job checks in, and if it goes quiet, we raise the alarm.
Heartbeat monitoring is included from the Starter plan. 14-day trial, cancel anytime.
Traditional monitoring watches whether something is up. A cron job that never fires is a different kind of failure. There is no request to catch, no exception to log, no downtime to detect.
A server reboot drops your crontab. Systemd disables the timer after an upgrade. The container gets rescheduled and never restarts the scheduler. Nothing errors because nothing runs. Your nightly backup has not fired in nine days and no one knows.
A database lock or an unresponsive upstream leaves the process stuck. It never exits, never logs a failure, never sends its completion ping. To every other tool it looks alive. A heartbeat with an interval catches the missing check-in.
Your background worker crashes at 3am. Jobs pile up in the queue. Emails do not send, invoices do not generate, exports never land. The app itself is up, so uptime checks stay green while the real work quietly stalls.
A slow deploy pushes the hourly sync to every ninety minutes, then every three hours. It still succeeds, so error tracking says nothing. A heartbeat interval treats late as an incident, because late data is often as damaging as no data.
One line in your cron script. Real incidents when it goes quiet.
No agent to install and no server access to grant. Your job simply reports in when it succeeds.
Add a Heartbeat monitor in PulseStack and give it a name and an expected interval, for example every hour or every night at 02:00. PulseStack generates a unique ping URL for that job.
Add one line to the end of your cron script or job. A simple curl to the unique URL is all it takes. HTTP and API monitors also support custom request headers if you need them.
Every successful ping resets the timer. If the next expected check-in does not arrive inside the expected interval, the job is considered failed and an incident opens.
Alerts fire after your configured consecutive-failure threshold across any of the 8 channels. When the job checks in again, PulseStack sends a recovery notification and closes the incident automatically.
Append a single ping to the unique URL PulseStack gives you. Every successful run resets the clock. Miss the window and the incident opens on its own.
# run your job as normal
pg_dump mydb > /backups/db.sql
# then check in with PulseStack
curl -fsS \
https://ping.pulsestack.io/hb/a1b2c3d4
# miss the interval = incident opensIt is not just a missed-ping flag. Every heartbeat plugs into the same incident, alerting and status-page engine as the rest of PulseStack.
Cron monitoring rarely lives alone. The same account watches your sites, APIs, DNS and domains from a single dashboard.
Watch a URL for status, response time and content.
Free and up
Alert when text appears or vanishes from a page.
Starter and up
Check a host answers at the network layer.
Starter and up
Confirm a specific service port stays open.
Starter and up
Validate JSON endpoints with custom request headers.
Starter and up
Dead-mans-switch for crons and background jobs.
Starter and up
Detect record changes and resolution failures.
Starter and up
Never lose a domain to a silent renewal lapse.
Starter and up
Alerts fire on failure and again on recovery, across 8 channels.
An honest look at how a silent cron failure plays out with each approach.
| Scenario | No monitoring | Uptime or error tracking | PulseStack heartbeat |
|---|---|---|---|
| Silent cron failure | Job never runs, nothing errors, no one is told | Passive uptime tools stay green, the app is up | Missed check-in opens an incident and alerts you |
| Hung or late job | Process stuck, no completion, no notification | Error tracking sees no exception to report | Interval plus grace elapses and the job is flagged |
| Recovery | You find out days later by accident | Manual log digging to confirm it is fixed | Automatic recovery notice and closed incident |
| Noise control | Every blip becomes a false alarm | Alerts on a single transient failure | Consecutive-failure threshold before alerting |
If a scheduled job matters to your business, someone needs to know the second it stops.
Backups, migrations, ETL pipelines and clean-up jobs run unattended overnight. Heartbeats turn every one of them from invisible into observable without adding a single log parser.
You inherit crontabs you did not write on servers you rarely log into. Drop a heartbeat on each critical job and you find out about a failed client backup before your client does.
No on-call rota, no ops team, just you. A dead-mans-switch on the jobs that keep the product alive means you sleep instead of guessing whether last night's sync actually ran.
A missed heartbeat can page your on-call rota, ping a Slack channel or open a webhook. Choose your channels and a consecutive-failure threshold to keep the noise down.
SMS and voice are available as an add-on and are included on the Team and Enterprise plans.
Heartbeat monitoring works on a dead man's switch principle. You configure a monitor with an expected check-in interval, and your cron job or scheduled task sends an HTTP request to a unique URL after each successful run. If PulseStack™ does not receive the heartbeat within the expected window plus a grace period, it marks the job as failed and triggers your configured alerts. This catches silent failures that produce no error output.
Add a single HTTP request to the end of your script. For a bash script, append curl -fsS --retry 3 followed by your unique heartbeat URL. For Python, add a requests.get() call. For Node.js, use fetch(). The request takes milliseconds and confirms the job completed successfully. If the script crashes before reaching that line, the heartbeat never fires and PulseStack™ alerts you.
Uptime monitoring actively checks your services at regular intervals by sending requests to your endpoints. Heartbeat monitoring is passive. It waits for your systems to check in. Uptime monitoring watches public-facing services like websites and APIs. Heartbeat monitoring watches internal processes like cron jobs, batch imports, data pipelines, and backup scripts that have no public endpoint to check.
Yes. Each heartbeat monitor has its own expected interval and grace period configured independently. You can monitor a job that runs every minute alongside one that runs weekly. The interval tells PulseStack™ how often to expect a check-in, and the grace period accounts for natural variation in execution time. Set the grace period to at least 20% of your expected runtime.
Basic heartbeat monitoring confirms execution, not correctness. For validation, you can include exit code checking in your script so the heartbeat only fires on success. You can also send a POST request with a JSON body containing metrics like rows processed or records exported. PulseStack™ can validate these values against thresholds you define, so a job that runs but processes zero records still triggers an alert.
Alerts fire as soon as the expected interval plus grace period expires without a check-in. For a job that runs every 5 minutes with a 2-minute grace period, you will be alerted within 7 minutes of a failure. Alerts go through any of the 16+ channels including email, SMS, phone calls, Slack, PagerDuty, and webhooks. There is no additional polling delay.
Yes. You can schedule maintenance windows that suppress alerts during planned downtime. This prevents false alarms when you intentionally stop services for deployments, migrations, or server maintenance. You can set one-time windows or recurring windows for regular maintenance schedules. Monitoring resumes automatically when the window ends.
Yes. Heartbeat monitoring works with AWS Lambda scheduled events, Google Cloud Scheduler, Azure Timer Triggers, Vercel Cron, Railway cron jobs, and any other serverless or managed cron service. Since these platforms handle scheduling externally, heartbeat monitoring is often the only way to verify that the function actually executed and completed without errors.
The free plan includes 50 monitors total, and heartbeat monitors count toward that limit. Each cron job you want to track requires one monitor. Checks on the free plan support 3-minute resolution, meaning the shortest expected interval is 3 minutes. Paid plans support 30-second resolution and higher monitor counts.
Yes. PulseStack™ logs every heartbeat received, including the timestamp and any payload data you send. The dashboard shows a timeline of successful check-ins, missed windows, and alert events. You can track execution patterns over days, weeks, or months to identify trends like gradually increasing runtime that may indicate a problem developing before it causes failures.
Add a heartbeat to your most important cron in under five minutes. If it ever goes quiet, you will be the first to know instead of the last.
Free plan available. No card required to start.