A Green n8n Status Proves Nothing

Over the course of one week, the n8n forum surfaced two analyses of the same phenomenon from different perspectives.

One engineer described runs that hang in the queue while the worker sits idle.

Another engineer collected cases where n8n marks a run as successful even though the provider on the other end never confirmed the result.

The triggers differ, but the cause is the same: the platform records that the code ran, not that anything changed in the real world.

For a company that relies on automation for its CRM, mailings, and payments, the difference between these two facts costs money.

A red run triggers an alert and a person to investigate.

Rerunning a non-idempotent POST—such as writing to a CRM or charging a payment—does not trigger anything.

It simply duplicates data, and this is discovered not by monitoring but by accounting or an unhappy customer.

This is exactly the problem faced by a team that described its case with self-hosted n8n, a Redis queue, and an MCP Server Trigger calling an external HTTP tool: duplicate CRM records from a single form forced them to build a temporary idempotency guard on top of the standard queue.

An important detail of their solution is that they deliberately rejected broad response caching because the cache also hides a legitimate repeat call with the same arguments.

Idempotency here is a separate logic layer designed for a specific business process.

A checkbox in the queue settings does not provide it.

A workflow with a couple of nodes and arrows looks simple.

A reliable workflow that can be trusted with a payment or customer mailing is never simple—it requires an idempotency key for every unsafe operation, a reconciler that asks the provider whether the reported action actually occurred, and lock timeouts calculated for the task’s real duration rather than taken as defaults.

That is what distinguishes an automation pipeline capable of handling the company’s workload and money from a macro that will one day fail silently.

When KT.Team puts n8n or MCP integrations on top of queues such as Kafka, this layer—reconciling the outcome with the provider and ensuring idempotency at the business-key level rather than the request level—is built into the project from the start, not added after the first duplicate-charge incident.