The heartbeat check: one weekly glance that catches silent failures

A heartbeat check is a five minute Friday ritual where you confirm your automations are alive by doing three things: check the run count, scan the error log, and push one end-to-end test entry. It catches silent failures before they cost you money or trust. That is the whole job.

• A heartbeat check is a five minute Friday ritual with exactly three steps and nothing more.
• The three checks are run count, error log, and one end-to-end test entry.
• Silent failures do not announce themselves, so you have to go looking on a schedule.
• A dropping run count often means a broken trigger, not a slow week.
• An end-to-end test entry is the only step that proves the whole chain still works.
• Putting the heartbeat check on your Friday calendar turns a good idea into a habit.

What is a heartbeat check?

A heartbeat check is a five minute Friday ritual where you confirm an automation is still running correctly by reviewing its run count, scanning its error log, and pushing one end-to-end test entry through the whole workflow. The name is the point. A heartbeat tells you something is alive. Your automations do not have a pulse you can feel, so you build one. Once a week, you press two fingers to the wrist of your systems and check.

Most automation platforms run quietly in the background. That quiet feels like success. It is not proof of anything. A Make.com scenario can stop firing and stay perfectly silent. A GoHighLevel workflow can skip a step and never tell you. The heartbeat check exists because working and silent look identical from the outside.

Working and quietly failing look identical from the outside, which is exactly why a scheduled heartbeat check matters.

Why do automations fail silently?

Automations fail silently because they are designed to run without supervision, so when a trigger breaks, a credential expires, or a step times out, nothing interrupts your day to tell you, and the workflow simply stops producing results while appearing untouched. No alarm. No red light. Just an absence of output that you do not notice until a customer does.

Here are the common ways the pulse stops:

• An expired API token quietly blocks every run after a certain date.
• A renamed field breaks the mapping, so data lands in the wrong place or nowhere.
• A third-party service changes its rules and rejects your requests.
• A trigger event stops firing, so the run count drops to zero without a single error.
• A step succeeds technically but sends an empty or malformed payload downstream.

Research backs this up. A longitudinal study of a production automation runtime found that roughly 70 percent of silent failures were caught by a human reading the output through a scheduled weekly review, not by an automated alert. You can read the taxonomy of silent failures in a production runtime for the full breakdown. The lesson is simple. A human glance on a schedule catches what silent systems hide.

The three checks, in order

The heartbeat check has three steps. Not four. Not ten. Three. The whole appeal is that it fits in five minutes on a Friday, so you actually do it. Adding steps kills the ritual.

1. Check the run count

The run count is the number of times an automation executed over a set period, and it is the fastest signal of life you have. Open your platform. Look at how many times each scenario or workflow ran this week. Compare it to a normal week. A count near zero on something that should run daily is a broken trigger until proven otherwise.

A run count that drops to zero is a broken trigger until proven otherwise, not a slow week.

2. Scan the error log

The error log is the running record of failed or interrupted executions your platform keeps automatically. Scan it. You are not debugging. You are noticing. Are there errors this week that were not there last week? Is one workflow throwing the same error over and over? A repeated error is a pattern, and patterns are what you fix. Guides like the Datadog best practices for monitoring pipelines describe filtering logs by status to spot exactly this.

3. Push one end-to-end test entry

An end-to-end test entry is a single real record you send through the entire workflow to confirm every step still connects. This is the step people skip, and it is the only one that proves the whole chain works. Run count and error log tell you the machine is moving. The test entry tells you the machine is producing the right thing at the far end.

Submit a test form. Create a fake lead named something obvious like “HEARTBEAT TEST.” Then follow it. Did it land in the right place? Did the tag apply? Did the email send? A workflow can pass every technical check and still fail the business, which is why end-to-end workflow testing exists as a discipline of its own.

What does a heartbeat check actually look like?

A heartbeat check looks like five minutes on a Friday afternoon where you open your automation platform, glance at run counts against a normal week, scan the error log for anything new or repeating, and send one test entry through your most important workflow. No spreadsheet. No report. Just your eyes and three questions.

Why Friday, and why five minutes?

Friday works because it lets you catch a broken automation before the weekend, when nobody is watching and a silent failure can pile up for two full days before anyone notices Monday morning. The five minute scope works because a short ritual gets done and a long one gets postponed.

The constraint is the feature. If your heartbeat check took an hour, you would skip it during a busy week, which is every week. Five minutes survives busy weeks. That is why the run count comes first and the deep debugging never enters the ritual at all. When the heartbeat check finds a problem, fixing it is a separate task for later. The Friday glance only has one job: find the silent failure.

The heartbeat check finds the problem. Fixing it is a different task, which is what keeps the ritual to five minutes.

Industry guidance on data pipeline monitoring makes the same case: unmonitored systems erode trust quietly through broken integrations and missing data, and the core health signals are throughput counts and error rates. The heartbeat check is that framework, shrunk to fit a small team’s Friday.

Fun fact: the term “heartbeat” is borrowed straight from engineering, where a heartbeat signal is a periodic message a system sends to prove it is still alive. When the heartbeat stops, the monitor knows something died. At Hot Hand Media we borrowed the name because it captures the whole idea in one word. No heartbeat, no life.

In my work with small business owners running Make.com and GoHighLevel automations, the pattern that shows up most is that the automation broke weeks before anyone noticed, and they only found out because a customer complained. Nobody was checking the run count. The workflow had gone quiet, and quiet got mistaken for fine. The owners who avoid this are not more technical. They just do a five minute heartbeat check every Friday, so a broken trigger surfaces in days instead of weeks. The habit beats the skill every time.

How do I know if my automation is broken if there is no error?

Check the run count first. An automation can break with zero errors when the trigger itself stops firing, so the workflow never runs at all. Compare this week’s execution count to a normal week. A count near zero on something that should run daily means the trigger broke, even though the error log looks clean.

How often should I check my automations?

Once a week is enough for most small teams. A weekly heartbeat check on Friday catches a silent failure before the weekend and keeps the habit small enough to actually maintain. High-volume or revenue-critical workflows may earn a second check midweek, but weekly is the baseline that survives busy schedules.

What is an end-to-end test in automation?

An end-to-end test is one real record you push through an entire workflow to confirm every step still connects and produces the right result. Instead of checking one piece, you follow a single entry from start to finish. It is the only check that proves the whole chain works, not just that individual steps are running.

Why did my automation stop working on its own?

Automations stop on their own when something outside them changes. Common causes are an expired API token, a renamed field that breaks the mapping, or a third-party service that changed its rules and now rejects your requests. Nothing in your setup changed, but the world around it did, and the workflow went silent.

What should I do when the heartbeat check finds a problem?

Write it down and make it a separate task. The heartbeat check has one job: find the silent failure. Fixing it is different work that should not eat your five minutes. Note what broke, when the run count dropped, and which error repeated, then schedule the fix so the ritual stays fast.

Can I automate the heartbeat check itself?

You can automate parts of it, like an alert when a run count hits zero, but keep the human glance. Research on production automations found that a person reading the output caught roughly 70 percent of silent failures that automated alerts missed. Alerts help. They do not replace the Friday check.

Which check matters most if I only have time for one?

The end-to-end test entry. Run count and error log confirm the machine is moving, but only the test entry proves the machine produces the right result at the far end. A workflow can pass every technical check and still fail the business, so when time is short, follow one real record all the way through.

Silent failures win when nobody is looking. The fix is not more software. It is a five minute glance on a schedule you keep. Pick your most important workflow, learn where its run count and error log live, and decide what a normal week looks like. Then run your first heartbeat check this Friday: run count, error log, one test entry.

Save this and put a heartbeat check on this Friday’s calendar. If you want more plain-language help building systems that do not quietly fall apart, visit Hot Hand Media.