How Do You Build a Heartbeat Check for a Scheduled Automation?

How do you know a scheduled automation stopped running?

You add a heartbeat check. Every time the automation finishes a run, it sends a small signal to a separate monitor. If the monitor does not hear from it within an expected window, it alerts you. This catches the failure that error alerts miss: the run that never started at all.

Most automation monitoring watches for errors. A step fails, the platform sends an email, someone fixes it. That covers loud failures. The quiet failure is different. A schedule gets paused by accident, a connection expires, an account hits a plan limit, or someone duplicates a scenario and turns off the original. Nothing errors, because nothing runs.

I build and maintain automations for lead routing, enrichment, and CRM sync, and the silent stop is the failure I worry about most. A broken run shows up in a log. A missing run shows up weeks later, when a sales rep asks why no leads came through.

What is a heartbeat check in automation?

A heartbeat check is a monitor that expects to hear from your automation on a schedule. The automation pings the monitor at the end of each successful run. The monitor tracks the time since the last ping, and when that gap passes a threshold you set, it raises an alert through email, Slack, or SMS.

The idea comes from operations work, where it is often called a dead man's switch. The logic is inverted from normal alerting. Instead of the system telling you something went wrong, you are alerted because the system stopped telling you that everything went right. Silence becomes the signal.

That inversion is why it works so well for scheduled jobs. An error alert depends on the automation running far enough to notice the error. A heartbeat depends on nothing except time passing, so it still fires when the automation is paused, deleted, or stuck before its first step.

Why are error alerts not enough for scheduled automations?

Error alerts only fire when a run starts and then fails. They stay quiet when the trigger never fires, the schedule is turned off, or the platform skips runs. For a scheduled automation, those silent cases are common, and they are exactly the ones that cost you the most time to notice.

Here are the silent stops worth planning for across Zapier, Make, and n8n. Someone turns off a workflow while testing and forgets to turn it back on. An OAuth connection to HubSpot or Google Sheets expires, and depending on the platform, the workflow may be switched off rather than sending an error on every run. A workspace runs out of tasks or operations for the month. A self-hosted n8n instance restarts after an update, and nobody checks that the schedule came back.

In every one of those cases, your error inbox stays empty. That empty inbox feels like good news. It is actually missing data. I covered the wider category in monitoring silent automation failures, and the heartbeat is the single most useful tool against it.

How do you build a heartbeat check step by step?

Create a monitor with an expected interval and a grace period, add a final step to your automation that calls the monitor's ping URL, and route alerts to a channel someone actually reads. Then test it by pausing the automation and confirming the alert arrives before you trust it.

Step one is choosing where the monitor lives. Dedicated cron monitoring services such as Healthchecks.io, Cronitor, and Better Stack are built for this. Each gives you a unique URL to ping. Check each vendor's documentation for current plans and limits before you pick one. If you prefer to keep everything in your own stack, you can build a simple version with an Airtable table and a second automation, which I cover below.

Step two is the ping. Add an HTTP request as the very last step of your automation, after the work is done. In Zapier that is a webhook action, in Make an HTTP module, and in n8n an HTTP Request node. Putting it last matters, because a ping at the start only proves the run began, not that it finished.

Step three is the alert route. Send it to a shared Slack channel or a named owner, not a general inbox nobody watches. Step four is the test. Pause the automation, wait past the window, and confirm the alert fires. An untested heartbeat is just another thing that might be broken.

How do you set the right interval and grace period?

Set the interval to match how often the automation is scheduled, then add a grace period that covers normal delays. A job that runs hourly might get a grace period of twenty to thirty minutes. A nightly job might get two hours. The goal is catching real stops without alerting on ordinary slowness.

Too tight and you get noise. Platforms sometimes queue runs, APIs slow down, and a long batch can take longer on a busy day. If your team gets three false alarms in a week, they will start ignoring the channel, and then the real alert gets ignored too.

Too loose and you lose the point. If a lead routing job that should run every fifteen minutes has a six-hour grace period, a stop on Friday afternoon might not alert anyone until the next working day. I set the window by asking one question: how long can this stop before someone outside the team notices? The grace period should be comfortably shorter than that.

Can you build a heartbeat check without a separate tool?

Yes. Have each automation write a timestamp to a record in Airtable or a Google Sheet when it finishes. Then run a second, independent automation on a schedule that checks those timestamps and alerts you when any of them are older than allowed. It is slower to set up but keeps everything in one stack.

The table is simple. One row per automation, with the name, the owner, the expected interval, and a last success timestamp. Each production automation updates its own row as its final step. The checker runs every hour or so, compares each timestamp to now, and posts to Slack when a row is overdue.

The catch is that the checker is itself an automation that can stop. If it lives on the same platform and the same account as everything it watches, a single outage takes both down. I put the checker on a different platform when I can, or I pair it with one external heartbeat that watches the checker. That small step closes the loop.

Which automations deserve a heartbeat check?

Any scheduled automation where a missed run would cost revenue, break a promise to a customer, or corrupt data quietly. Lead routing, CRM sync, enrichment jobs, invoice and billing tasks, and content publishing pipelines are the usual candidates. A once-a-month internal report probably does not need one.

I sort automations by blast radius. If this stops for a day, who notices first, and what does it cost? When the answer is a prospect who never got a reply, or a customer whose record never synced, the automation gets a heartbeat. When the answer is that someone on the team will notice at the next meeting, a heartbeat is optional.

The production automations I run for Ajust, built on Airtable and WhaleSync, are a good example of why this matters. When a sync sits underneath real case delivery, a missing run is not a technical detail. It is work that does not happen. That is the standard I use when deciding what gets monitored.

Who should own the alert when a heartbeat fails?

A named person, not a team. Every heartbeat should have one owner who receives the alert, knows how to restart the automation, and has a backup for when they are away. A heartbeat that alerts a shared inbox with no owner is only slightly better than no heartbeat at all.

Write the owner's name into the monitor itself and into your automation inventory. When the alert fires, the message should say which automation stopped, when it last succeeded, and where the runbook lives. That turns a vague alarm into a five-minute fix.

For revenue automations, the owner question overlaps with on-call planning, which I wrote about in who should be on call for revenue automations. If you already have that rota, plug heartbeat alerts into it. If you do not, start with one person and a backup. That is enough for most small teams.

What should you do next?

List every scheduled automation you run, mark the ones where a silent stop would hurt, and add a heartbeat to the top three this week. Give each one a sensible interval, a grace period, and a named owner. Then pause each automation once to prove the alert actually fires.

This is one of the cheapest reliability upgrades in automation work. It takes an afternoon, it needs no rebuild, and it changes how you find problems. Instead of a sales rep telling you leads stopped, your monitor tells you within the hour.

If you want help auditing your automations or setting up monitoring that your team will trust, reach out through pravinkumar.co. Let's chat about which of your workflows would hurt most if they went quiet.