How Do You Know an Automation Is Still Working?

How do you know an automation is still working?

You do not, unless you built something that tells you. Automations fail silently far more often than they fail loudly, and the default state of most workflows is that nobody finds out until a customer asks why they never heard back. Error alerts catch the loud failures. Nothing catches the quiet ones.

This is the difference between an automation you built and an automation you run. Building ends when the thing works. Running means knowing, on any given morning, whether it is still working, and that requires a deliberate second system whose only job is to watch the first one.

The Ajust workflow I maintain runs on Airtable with WhaleSync between systems, and it has delivered more than 25,000 cases, helped more than 400,000 people, and saved more than 50,000 hours. Numbers like that only accumulate if somebody notices when the flow stops, and noticing is not automatic.

Why do automations fail silently instead of loudly?

Because most failures are not errors. An error happens when a step tries something and the platform refuses. A silent failure happens when every step runs correctly and the work still does not get done, usually because nothing arrived to process or because what arrived did not match what the filter expected.

The classic version is a filter that quietly stops matching. Somebody renames a field, changes a dropdown value, or adds a required option, and your condition now matches zero records. Every run completes successfully. The logs are clean. The automation has effectively been switched off and it is still reporting green.

The second version is an upstream change you were never told about. A form gets replaced, a webhook gets pointed somewhere else, an integration gets reauthorised under a different account. Your side of the pipeline is perfectly healthy and simply has nothing to do, which looks identical to a quiet week.

What should you monitor instead of errors?

Expected volume, not exceptions. The most useful monitor for any automation is one that knows roughly how much should happen in a given period and complains when the number falls outside that range. Zero is the number that matters most, and zero almost never raises an error.

Think about what normal looks like for each workflow. A lead router that usually handles somewhere between five and fifty records a day should alert if it handles none for two days. A nightly sync that usually moves a few hundred rows should alert if it moves three. These thresholds do not need to be clever. They need to exist.

The second thing worth monitoring is freshness rather than throughput. Instead of counting runs, look at the newest record in the destination and ask how old it is. If the most recent synced row is four days old, something is wrong regardless of what the run history claims. Age of newest output is the single best proxy for whether a pipeline is alive.

What does a heartbeat check actually look like?

A small scheduled job that verifies something true about the destination and tells you when it stops being true. Not a monitor of your automation platform, which mostly reports on itself, but an independent check of the real world outcome the automation is supposed to produce.

In practice this means something that runs on its own schedule, queries the destination system, applies one or two thresholds, and sends a message only when a threshold is breached. The important property is independence. If the heartbeat lives inside the same workflow it is watching, then whatever kills the workflow kills the watcher, and you have built a smoke detector that switches off during fires.

Keep it boring. A heartbeat that tries to diagnose the problem will itself become a thing that breaks. Its job is to say that something is wrong and where to look, not to be clever about why. I have written about how the boundaries between stages are where failures hide in designing handoffs in multi-step automations, and a heartbeat is essentially a check placed at the last boundary.

How do you avoid alert fatigue?

By making every alert mean that a human must act. The fastest way to destroy a monitoring system is to send notifications for things that turn out to be fine, because people learn within about two weeks to ignore the channel, and after that you have monitoring in the technical sense only.

My rule is that an alert should be rare enough to be surprising. If an automation alerts weekly and the answer is usually nothing, either the threshold is wrong or the workflow is genuinely unstable, and both of those are problems to fix rather than noise to tolerate. Tuning thresholds until alerts become rare is not weakening the monitoring. It is what makes it survive.

Separate the two kinds of message as well. Something being broken deserves an interruption. Something being worth reviewing deserves a summary you read on a schedule. Mixing those into one channel means the urgent things get the same attention as the informational ones, which is to say, eventually none.

Who owns an automation after it is built?

Somebody by name, or nobody in practice. This is an organisational answer to a technical question and it is the one that determines whether monitoring gets acted on. An alert that arrives in a shared inbox where three people could respond is an alert that two of them will assume the third handled.

The ownership needs to include permission as well as responsibility. If the person who notices cannot pause the workflow, fix the filter, or contact the vendor, then noticing does not help. I have seen careful monitoring produce timely alerts that sat unactioned for days because the person watching had to escalate to somebody who was away.

For client work I make this explicit at handover. Someone named is responsible, they know what normal looks like, and they know what to do first. For the HubSpot and Zapier automation I run for Kismet Health, and for the Airtable work on Ajust, the value is not only in the build. It is in somebody knowing what should be happening and being able to tell when it is not.

What should you write down before you need it?

What normal looks like, and what to do first. Two short paragraphs per automation, written while you still remember, are worth more than any diagram. Six months later, the person looking at a broken workflow, possibly you, will not remember whether forty records a day is high or low.

The normal description should include typical volume, typical timing, what the output looks like when it is right, and which systems are involved in what order. The first-response description should say how to check whether data is flowing, how to pause it safely, and who to contact at each vendor. That is the whole runbook and it fits on one page.

Write it at build time rather than at incident time. Nobody has ever written a good runbook during an outage, and the version written under pressure tends to describe that one incident rather than the system. If you maintain automated reporting for clients, the same discipline applies to anything running on a schedule, which I touched on when writing about putting client reporting on a schedule.

How often should you actually look?

Weekly for a glance, monthly for a proper review, and immediately when something alerts. The glance is checking that volumes look ordinary. The review is asking whether the thresholds are still right, since a business that grew will make an old threshold meaningless in the quiet direction.

The monthly review is also where you catch drift that no threshold would flag. Fields that were renamed but still map, records that are being processed but into the wrong bucket, duplicates accumulating slowly. These are not failures. They are the workflow doing the wrong thing reliably, which is more expensive and much harder to see.

Put the review in a calendar rather than trusting yourself to notice. This is the least glamorous advice in this article and it is the one that separates automations that last years from those that quietly stop mattering. What breaks first is rarely dramatic, which I have written about in what breaks first when an automation scales.

What should you do next?

Pick the automation whose failure would embarrass you most and answer one question: if it stopped working right now, how would you find out? If the honest answer is that a customer would tell you, you have found the thing to fix today, and it is probably an afternoon of work.

Then build the smallest possible heartbeat for it. Something independent that checks the destination, knows one threshold, and messages you when that threshold breaks. Do not try to monitor everything at once. One workflow with a real heartbeat beats a monitoring plan for twelve that never gets built.

If you are running automations you depend on and cannot say with confidence that they ran correctly this week, that is worth fixing before anything else gets built on top of them. Reach out if you want help working out what to watch.