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 as soon as a missed check-in is confirmed, 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://pulsestack.co.uk/api/heartbeat/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, SSL certificates, 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 accepts a TCP connection, and how fast.
Starter and up
Confirm a specific service port stays open.
Starter and up
Check endpoints with custom headers and the status code you expect.
Starter and up
Dead-mans-switch for crons and background jobs.
Starter and up
Alert when a record goes missing or stops matching what you expect.
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 | Automatic re-check 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 an automatic re-check keeps the noise down.
SMS is available as an add-on and is 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.
Heartbeat monitoring confirms execution, not correctness. For validation, add checks to your script so the heartbeat only fires on success, for example when the exit code is zero or when the job processed at least one record. A job that runs but fails your own checks then skips its heartbeat, so PulseStack™ still raises 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 8 native channels, including email, SMS, 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.
Heartbeat monitors are not part of the free plan, which covers 5 HTTP monitors with 5-minute checks. Heartbeat monitoring starts on Starter, which includes 50 monitors, and each cron job you want to track uses one of them. The shortest expected interval is 60 seconds on Starter and 30 seconds on Pro, Team and Enterprise, which also raise the monitor limit. Every paid plan has a 14-day free trial with no card needed.
Yes. PulseStack™ logs the timestamp of every heartbeat received. The dashboard shows a timeline of successful check-ins, missed windows, and alert events, and check history is kept for 30 days, so you can spot patterns such as a job checking in later than usual 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.