n8n in Production: Green Status Does Not Prove Results

Four posts about one question

Four different posts appeared on the n8n forum over several consecutive days.
A freelancer sells monitoring together with the workflow.
The author suggests testing data extraction from invoices before building the pipeline.
The author shares an approval workflow for AI drafts through Slack.
Another shows how to remove an API key from plain text.
All four address the question: how do you know that the automation did what it was built to do?
My point is this: a production workflow is judged by a verified result, and a green run status does not guarantee one.

Silence as the costliest failure

The author of one of the posts, a backend engineer, writes that he ships every workflow with alerts for failed runs and runs that have stopped silently.

He builds the monitoring for n8n himself and argues that “no error” too often means “nothing happened.” The mechanics are as follows.

A crash with an exception is visible: n8n marks the run as failed, and Error Trigger catches it. Now consider two silent cases.

The schedule trigger stopped firing.

Or the webhook stopped arriving after the address was changed in the CRM. In both cases, there is neither an error nor an alert.

Leads stop reaching the CRM, the log is clean, and a sales manager notices the loss two weeks later when asking where the inquiries went.

Critical workflows need two types of control

The first catches an execution error. The second checks an expectation: “there must be at least N runs in the past hour”

, “the last successful run was within the past 24 hours”

The second type is harder because you need to know in advance what volume is normal for the process.

Valid JSON and an incorrect invoice

The second post focuses on a document-processing platform built with n8n and LLMs.

A discussion participant suggests separating extraction quality evaluation from orchestration assembly.

His argument: the model response passes schema validation while still containing incorrect values.

The `total` field is present, but its value is different.

The first step he proposes is worth remembering: - one document type; - 20 anonymized samples; - benchmark values and normalization rules for dates, currency, and separators; - comparison of extracted fields with the benchmark and a report for each document: what was missing, what was incorrect, and where validation failed.

The result is packaged as a rerunnable Python test harness.

Twenty benchmarked documents cost significantly less than a month of operating blindly. The claim “the model reads invoices well”

becomes a number, for example, 17 of 20 invoices were extracted completely

This number can be compared after changing the model, prompt, or OCR. Without it, every pipeline change remains unverified.

Assess where AI can deliver impact in your process

clients@kt.team Telegram @kt_team_it

A human in the loop where errors are costly

Third example: a seven-node workflow

An RSS trigger, post draft creation, a Slack message with Approve and Reject links, then a Wait node that pauses execution and resumes it after a click.

Approved content goes to publication; rejected content goes to the archive.

The author writes that most content automations write and publish in a single run, so no human sees the draft.

The Wait node acts as a safety mechanism here.

While the execution is waiting, it does not hold resources: its state is saved, and a link from Slack resumes it.

The step takes about ten seconds of an editor’s attention.

Skipping the step can result in a poor post being published under the company’s name.

This leads me to a rule: autonomy should be granted in proportion to the cost of an error.

An internal report can be sent without approval.

A brand post, payment, or customer email should require approval until tests show that the model consistently produces the expected result.

Secrets in execution history

The fourth post looks minor but concerns security

The Billbee API requires Basic Auth and a separate header with the developer key, while the HTTP Request node accepts one credential.

That is why the key is often placed in “Send Headers” as plain text.

The author lists where the key ends up:

in the workflow itself
in version history
in failed-run data and emails
where someone forwarded the error object

His solution: a custom credential that stores both parameters, leaving only a reference to it in the workflow. The same applies to LLM steps.

OpenAI or Anthropic keys in nodes, along with prompts and responses containing personal data in execution logs, eventually become a data leak.

For this, at KT.Team we are building an LLM & Security Gateway: a single point through which model calls pass, with policies, masking, and auditing. The workflow contains only the gateway address.

Minimum standard

Stripped of details, this is the minimum standard for production automation on n8n or any other orchestrator: - alerts for failures and for “silence” against expected volume; - a benchmark set for an LLM or OCR step, with accuracy measured before launch; - human approval wherever an error is visible to customers or costs money; - secrets in credentials and behind a gateway, never in node fields. None of these requires complex technology.

It takes discipline and engineering time, and that is where the tool shown in the demonstration differs from a process that can handle production load. In our integration projects involving MCP, RAG, and AI-native integration, connecting a model to a system takes days, while quality control and observability consume most of the work.

Verdict

In my view, automation that cannot report when it has stopped is worse than a manual process: a person doing the work manually will at least notice that it was not done. I evaluate a workflow with three questions. Will I know within an hour that it has stopped?
Do I know the accuracy of its LLM steps as a percentage?
Who presses the button before an irreversible action?
If even one question has no answer, you have a prototype, and it is reasonable to treat its budget as an experiment expense.