The Automation Stopped and Nothing Told Us

A workflow we had built stopped running for five days.

It had error notifications. They worked. They just never fired, because nothing errored. The workflow was not failing, it was not running at all, and a thing that is not running produces no errors to report.

Orders stopped flowing into the tracking database. Nothing else looked wrong. No alert, no failed run, no strange output to notice, because there was no output at all. The client worked it out before we did, which is the part I think about.

We added a heartbeat check afterward. Something that expects the workflow to report in, and raises a flag when it doesn't. It is a small piece of work and it should have been there from the start.

I open with it because it is the exact gap most monitoring has. Error alerting answers "did something go wrong." It does not answer "did anything happen at all," and those are different questions.

Nobody reads the dashboard

The other common approach fails differently. Someone builds a dashboard. It is a good dashboard. It gets opened maybe six times, then never again.

The reason is not laziness. A five-person business has nobody whose job is to look at things that are probably fine. Checking a normal dashboard produces nothing, and work that produces nothing gets dropped the first week things get busy. That is the correct instinct. The monitoring design is what is wrong.

So invert it. Nothing demands your attention while things are normal, and something reaches you the moment they are not.

Exception reporting

No urgent message arrives when things are normal. The owner of a workflow hears from it only when a threshold is crossed. Volume moved outside its usual range. The correction rate doubled. A run took four times as long as it should. Expected output did not appear.

That last one is the lesson from the opening, and it needs to be built deliberately. A scheduled check that asks whether the thing that should have run did run catches a category of failure that error alerts structurally cannot.

Silence is only information if something is listening

"No alerts this week" tells you nothing on its own, because the monitoring can fail the same way the workflow did. A dead alerting path is silent, and a healthy system is silent, and from the outside they look identical.

So the monitor needs its own heartbeat. Something that reports in on a schedule and says the checks ran, whatever the result. A weekly digest saying "all expected checks ran, nothing outside range" is enough. It is the only message you want arriving on a normal week, and its absence is itself a signal.

If a workflow matters enough, put the check somewhere other than the system it is checking. A heartbeat that lives inside the thing it monitors goes down with it.

Set thresholds from real data, tuned to consequence

Set something provisional on day one, based on what you expect the volume to be and what it would cost you to be wrong. Rough numbers are fine. What is not fine is a workflow touching payments or customer records running unwatched for its first month while you gather data on it.

Then tune. After a full business cycle, look at the actual range. If weekly volume sat between 30 and 50, move the alert outside that band with room to spare. You are not trying to catch every fluctuation. You are trying to catch the week it goes to 6.

How fast you need to know is a separate question, and it follows consequence rather than company size. A workflow producing internal summaries can be checked daily. A workflow touching payments, access permissions, customer messages, or bookings needs a shorter loop, because those are hard to walk back and the damage compounds while you are unaware. Ask how long the failure can run before it becomes expensive, then check more often than that.

Revisit the numbers twice a year. Normal moves, and a workflow tuned to a business half your current size starts crying wolf as you grow.

Rare, or it stops working

An alert that fires weekly becomes a filter rule within a month. Then it goes to a folder nobody opens, and now you are worse off than having no alerts, because everyone believes something is watching.

For low-consequence workflows, wider thresholds are usually the better tradeoff. Reserve the interrupt for conditions that actually justify attention, and let the monthly sample catch the smaller deviations. Nothing catches anything through a channel people have stopped reading.

For the workflows that move money or touch customers, tighten the thresholds and accept the higher alert volume that comes with them. Those are worth being interrupted for. But if the volume climbs past what the owner can actually act on, that is itself a sign the thresholds need tuning, not just a cost of doing business.

One name on it

Alerts go to a person, not a shared inbox and not a channel. Shared destinations produce the situation where four people see the message and each assumes one of the others is handling it.

Add one rule: if an alert is not acknowledged within the window you set for that workflow, it goes to a second person. That covers vacation, illness, and the ordinary case of someone seeing it on their phone at 6pm and forgetting by morning.

Acknowledgement only proves someone saw it, not that the problem is fixed. An alert can sit acknowledged and unresolved for days. For higher-consequence workflows, also decide how long an alert can stay unresolved before it escalates again.

If your company is small enough that both names are you, fine. Write it down anyway. The point is that the answer exists before you need it.

Building it once in n8n

Do not build error handling into each workflow separately. Build one workflow that receives failures, formats them, and routes them to the right person.

The mechanics are worth getting right, because this trips people up. n8n has an Error Trigger node for exactly this, but other workflows do not call it. You select the error workflow in each monitored workflow's settings, one by one. Miss that step and the workflow is unmonitored while looking monitored, which is worse than knowing it is unmonitored.

Two things about it that surprise people. The Error Trigger fires on automatic executions, not on manual ones, so testing by clicking execute will show you nothing and you may conclude it is broken. And it only fires on failures, which brings you back to the opening: a workflow that stops running never errors, so this alone would not have caught the five day outage.

That is what the second workflow is for. A scheduled job that checks whether the others actually ran and produced output, compares volume and duration against your stored numbers, and sends anything that looks off down the same path. This is the piece that catches absence.

One practical detail. n8n prunes finished execution data by default after 336 hours, which is 14 days. Anything reading run history to build a picture of the last quarter will find two weeks of it. So write the numbers out as you go, appending run counts and durations to a sheet or table on a schedule, instead of reconstructing them later from history that is no longer there.

Two shared workflows give you the foundation: one routing errors, one checking that things ran. Change how alerts are formatted or where they go and you change it once. Add your twelfth automation and most of the monitoring is a settings entry rather than a build.

They do not cover everything. Each automation still has to emit the signals worth watching, and the ones that move money or touch customers usually need a quality check of their own on top. Shared plumbing, specific checks.

The quarterly page

Alerts catch the sudden stuff. Slow drift needs something periodic, and one page per automation per quarter is enough.

What it ran and how much. What changed, from your change log. How often a human corrected the output. What the monthly samples found. Any alerts or incidents during the quarter, and whether they were closed. Anything still open.

Keep it to a page so it stays easy to maintain. Let it grow past a page and it becomes a document nobody writes.

That page has a second use. When a larger customer asks how you control automated processes, this is the answer: a record showing you have been watching the whole time. That is much stronger evidence than a policy written for the questionnaire, and that is what part four is about.

What you probably don't need, and what you might

You do not need an enterprise evaluation platform, a model observability suite, or anything with a leaderboard. Those exist for teams building models.

You may still need a small test set of your own. If a workflow classifies, summarizes, or recommends, keep a handful of cases where you know the right answer, including the ones that have burned you before, and run them after any change to the prompt, the tool, or the data source. Twenty examples in a spreadsheet counts. It is the difference between hoping a change was safe and having some evidence that it was.

Coverage beats sophistication. Every workflow having a crude threshold and a named owner beats one workflow with beautiful instrumentation while eleven run unwatched.

Where to start

Get every workflow you already have reporting through one path this month, even if the only thing you check at first is whether it ran. Then add the weekly digest so you know the checking itself is alive.

If you build the error workflow and the heartbeat checker as a reusable pair, future automations can plug into the same monitoring path instead of each getting their own. Thresholds and owners still need attention as things change.

Sources

1. The Error Trigger node, and the fact that it fires on automatic executions rather than manual ones: n8n Error Trigger documentation.
2. Default pruning of finished execution data after 336 hours: n8n execution data documentation.
3. NIST AI 800-4, "Challenges to the Monitoring of Deployed AI Systems" (Center for AI Standards and Innovation, March 2026), on risk-based monitoring and monitoring cadence as open operational questions: NIST.
4. The five-day outage described at the top is our own, recounted without identifying the client.
5. n8n defaults can change between versions. Check the pruning setting on your own instance rather than assuming the documented default.

A note on images across this site. Illustrations and workflow diagrams are made with AI, from prompts we write and refine, and we edit most of them afterwards. Screenshots taken in n8n are not, since they show workflows we built in the tool.