How do you notice when a client automation silently stops?

Feedback General
1

How do you catch a client workflow that stops quietly?
Not selling anything, just trying to understand how people handle this in practice.
If you run automations for clients rather than for your own business: the last time one stopped without throwing an error, how did you find out? You, an alert, or the client telling you?
And what did it cost you when it happened? Time to fix, or something worse than that?

Describe the problem/error/question

What is the error message (if any)?

Please share your workflow

(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)

Share the output returned by the last node

Information on your n8n setup

  • n8n version:
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app):
  • Operating system:
2

Honest answer to your first question, because I think it is the useful one: the last few times, the client told me. Not an alert, not me. That is the whole reason the question is worth asking.

The reason is structural, and it took me too long to see it: almost every alerting setup we build is wired to errors, and a workflow that quietly stops does not produce one. The Error Trigger fires when something throws. Nothing throws. There is no run to attach an alert to, because the absence of a run is the event. You cannot alert on a thing that did not happen by watching the things that did.

Two different failures hide under “silently stopped”, and they need opposite instruments:

1. It stopped running. The only thing that catches this is a dead man’s switch: something outside n8n that expects a ping every N minutes and shouts when the ping does not arrive. Cheap version, no new tools: a scheduled workflow that queries the executions API for “last successful run of workflow X” and screams if it is older than the interval. Note it has to live outside the instance you are watching — if the instance is the thing that died, its own watcher died with it. That mistake cost me a week once.

2. It ran, it went green, and it did nothing. This is the nastier one and the dead man’s switch is blind to it, because the pings keep arriving. An empty array from an upstream API, a filter that now matches zero items, a credential that expired into a 200-with-an-error-body, an AI step returning an apology instead of the JSON. The run is a success by every measure n8n has. The only thing that catches it is an assertion on the output: item count, a required field being non-empty, a value inside a plausible range — checked in the workflow, failing loudly on purpose.

On your cost question I can only give you the half I actually measured, so I will say which half. I do not have a clean number for how long these sit undetected — that is the number I would most like and nobody seems to have it, which is part of why it stays expensive. What I do have is how common the precondition is: across 2,061 real n8n workflow exports, 97.6% had no error handling wired at all. Those are community exports rather than production instances, so read it as a description of what gets shared, not of your setup. But it does say the default state is a workflow with nothing in it that could speak up.

The uncomfortable general rule I now work from: green is not evidence. Green means nothing threw. Whether the work happened is a separate question, and if nobody wrote a check for it, nobody is checking it.

That gap is what I ended up building a tool around — it reads a workflow export and lists the places it can go green while doing nothing. Not pitching it at you since you said you are not shopping; happy to run one of yours through it and just send you the list if it is useful.

3

The reply above covers the case where no run happened, and it covers it well. There is a second failure underneath that one, and it needs a different instrument, because here the run does happen and everything about it looks right.

The workflow executes on schedule. Every node goes green. Something is written at the other end. And the content is wrong, or it came from somewhere nobody intended.

Mine was a CV screener reading PDFs out of Gmail. The Gmail trigger was on its default, which returns metadata rather than attachments, so no PDF ever arrived. It scored the covering email instead and wrote a plausible number to a sheet on every single run. A cadence check would have been perfectly happy with it. It ran exactly on time, it produced exactly one row per candidate, and the row was meaningless.

On your second question, what it cost. The awkward part was not the fix, which took minutes once I knew. It was that I could not tell you which of the earlier runs had been wrong, because nothing distinguishes a good row from a bad one after the fact. That is the real bill. Not the repair, but everything downstream you can no longer vouch for.

Two things have worked for me since.

Run every integration once against a local server whose only job is to log the outgoing request body, then read it. Twenty minutes per integration, and it has found something every time I have done it.

Then have each extraction carry a provenance field, set by the node that physically read the data rather than by anything further along. attachment_pdf, email_body, manual. Assert on it before the write. The screener now only accepts attachment_pdf, so the moment it starts scoring covering emails the run fails loudly instead of writing a confident 100.

For what it is worth, the honest answer to your first question is that I found mine by accident, during a demo. It had been green for months.

4

This is the shape that breaks the instruments in the reply above yours. A dead man’s switch is happy because it ran on time. An assertion on output volume is happy because it produced exactly one row per candidate. The only thing that catches yours is knowing where the data came from, and almost nobody checks that.

The way you put the cost is the most useful sentence anyone has given me: not the repair, but everything downstream you can no longer vouch for.

I should say I am asking this on r/n8n as well, and here is what I can hand back. Across everyone who has answered me in both places, not one person was alerted by their own monitoring. Every single one found out from a human downstream, or by accident, like you did during that demo.

Three things if you have the patience. Was that CV screener for a client or in house? Did anyone have to be told afterwards, or was it something you could quietly correct? And the twenty minute integration check, do you run that on every new build now, or only on the ones that have already burned you?

1 « J'aime »
5

Neither, and that is worth flagging because I think it makes me a different case from most of the people answering you.

It was a product. Built to sell as a template, not run for a client. So there was no operator watching a dashboard and no downstream human waiting for a report. That matters for your sample: everyone else answering you seems to be running automations for clients, and they found out because a person downstream complained. I had no downstream person to complain.

Which answers your second question, and not flatteringly. Nobody had to be told, because nobody had bought it. The thing was on sale and broken, and the only reason that cost nothing is that it had no customers. That is luck, not process. If it had sold in week one I would have shipped a scoring tool that rated covering emails to someone who trusted it.

On the twenty minute check: only the ones that had already burned me, and I want to be precise about that because the honest version is the useful one. All five products got that treatment after they shipped, not before. I ran it the first time because one workflow was behaving oddly, and the reason it is now on every build is not discipline, it is the base rate. Nine defects across five workflows, and not one of the five was clean. Once your hit rate is five out of five, “only when suspicious” stops being a policy and starts being a way of not looking.

The thing I would add to your finding, since you shared it: your sample is going to under-report the case I had. You are hearing from people whose automation worked and then stopped, because that is the shape that produces a downstream human with a complaint. The workflows that never worked at all do not generate that signal. There is no angry client, because nothing they were promised ever arrived to be missed. It just sits there being green.

I only found mine because I happened to run one properly during a demo. If you are looking for the ones that were wrong from birth, the people who have them mostly do not know yet, and they will not turn up in a thread asking how you found out.

6

This is the most complete answer I have had anywhere, and the framing is what I will keep. You cannot alert on a thing that did not happen by watching the things that did. And green is not evidence.

Straight answer to your offer: I have nothing to run through it. I do not run automations for anyone. I am a video editor who kept hearing this same story and wanted to understand it properly before deciding whether it is worth building something for. Nothing exists yet, and “not selling anything” in the post was literal.

I have been asking the same question in parallel on r/n8n, and I can trade you something for the number you said you want. You said you have no clean figure for how long these sit undetected and that nobody seems to. People keep answering me with durations: nine days, eight days, four days, four days, about a week, your week, and the reply just below yours here that had been green for months before it turned up by accident during a demo. Small sample, self-reported, all from public threads. It is still a distribution, and I am happy to send you every one verbatim whether or not you answer the next bit.

Which is the builder to builder question, since we are looking at the same thing from opposite ends. Has anyone paid you for it yet? And when you have tried to charge, what do people actually say? Every practitioner who has answered me, here and on Reddit, built their own fix, and not one mentioned buying anything. I cannot tell whether that is because the tools are young or because this is a problem people would rather solve than pay for.

Last one, since you said the client told you: do your clients ever see any of this? A status page, a monthly note. Or would you rather they never thought about it?

1 « J'aime »
7

Yes to the trade, and thank you. I would like every one of those durations verbatim, including the ones that make the distribution look untidy.

Now the honest answers, which are worse than you are probably expecting.

Has anyone paid me for it yet. No. Not once. Five products have been on sale for about five months and have made zero sales, from 99 page views in total across all of them. That is not a rounding error, it is the actual number.

What do people say when I try to charge. I genuinely cannot tell you, because I have barely asked. One proposal on Upwork, no reply yet. Four emails offering a free audit, sent Saturday, no replies yet. That is the entire sales history. So when you ask what people say when you charge, I am not a useful data point. I have not put the question to enough people to have heard an answer.

I want to be careful about what my zero proves, because it is tempting to read it as evidence for your hypothesis and it is not. 99 views is not a market test. It is not enough traffic to distinguish “nobody wants this” from “nobody has seen it”. My failure so far is a distribution failure, and I would be misleading you if I let it stand as evidence about willingness to pay.

Do my clients see any of this. I have no clients. The CV screener was a product, not client work, which is why nobody had to be told when it turned out to be broken. So I have never had to decide whether to show someone a status page, and I would not trust my own answer if I speculated.

Here is the one thing I have that does bear on your question, and it points your way rather than mine. The Jobs category on this forum has had roughly ten “[For Hire]” posts in the last few days selling almost exactly this, two of them nearly word for word. Every one has zero replies. I counted nine separate people building or selling silent-failure tooling in two threads, including me and including you, and I have yet to see one visible customer.

That is not proof people will not pay. It is proof that the sellers currently outnumber the buyers who are looking, which is a different and more fixable problem, and it is the thing I would want to know if I were deciding whether to build something.

The only thing that has worked for me is this. Answering a question someone actually asked. Two threads, two people who changed something. Nothing I have broadcast has produced anything at all.

8

You are right. My question selects for cases that were found. The ones that were wrong from birth have no angry client and no duration, so they cannot turn up in a thread asking how people found out. I am going to write that down against my own data rather than quietly ignore it.

Nine defects across five workflows, and none clean, is the most interesting number I have collected. So the last thing I want to ask you: given that base rate, have you ever paid for anything that does that twenty minute check for you, or seriously considered it? You build products, so you will know the difference between a thing you would buy and a thing you would only ever build.

1 « J'aime »
9

No, and I would not. That is the honest answer, and it is worth being precise about why, because the reason is more interesting than the answer.

The twenty minute check is about thirty lines of Node. A server that accepts any request, writes the method, the URL and the raw body to stdout, and returns a plausible response. I wrote it in an afternoon and I would write it again rather than pay for it. As a product it is worthless, and anyone competent enough to need it is competent enough to build it in less time than it would take to evaluate a purchase.

So if you are asking whether the tool is a product, my answer is no, and my own behaviour is the evidence.

But the tool was never the expensive part. Three things were, and none of them package.

Knowing to do it at all. I shipped five products and sold them before I ran one properly. The check cost twenty minutes; not doing it cost months. Nobody buys a check for a problem they do not believe they have, and the base rate is invisible until you look. That is the real barrier and it is not a pricing or feature problem.

Knowing what to look for. The raw log is just bytes. Recognising that {"":""} means the payload went into the wrong parameter, or that a well formed request carrying a covering email instead of a PDF means the trigger was returning metadata, took me nine specific defects to learn. That knowledge is the asset and it does not fit in a download.

Automating the knowing. I tried. I wrote a scanner to find those defect classes statically, pointed it at 3,138 published templates, and the first run flagged 58 of the first 83. All false. Nine rounds of fixes to get it honest, and even now it catches about half of what a labelled corpus contains. The gap between “I know this failure” and “I have encoded this failure” is much wider than it looks.

Now the part that matters for what you are deciding.

Your finding and my behaviour agree, and I think the mechanism is this: the population who would pay is people who have just been burned. That group is small, and worse, it is transient. By the time they would buy, they have already learned the lesson and built the thirty line server. I am a member of that population and I still would not buy.

What I might have paid for is different, and it is not a tool. If someone had emailed me in July saying “your CV screener is scoring covering emails, here is the line”, I would have paid for that immediately, because it is a finding rather than a capability. That is a service, it does not scale, and the person delivering it has to already know the nine things.

I should say plainly that I have no evidence for even that. I have sent eleven emails of exactly that shape, findings with no offer attached, and not one has been answered yet. So treat my “I would have paid” as a claim about myself, not a market.