n8n Agent Got a 200 OK, but the Customer Saw an Empty Chat: Anatomy of a 'Silence Bug'

Green nodes, a 200 OK from Meta, and an empty chat on the customer's side. That is the second 'silence bug' in an n8n-based AI agent, the subject of a new write-up on Habr. It is already the author's second story of this kind, and the wording makes the key point clear: the system believed it had done its job, while the human was left without an answer. The announcement is short, so what follows covers only what it states, plus the general mechanics that cause this in messaging agents.

What the write-up reveals

The announcement offers few facts, but they are telling. The n8n workflow ran without errors: every node turned green. The request to the Meta API returned 200 OK. Even so, the user never saw the agent's reply, and the chat was empty. The announcement does not specify which channel was involved or at what point in the chain the text disappeared. The details remain in the full article on Habr.

For AI agents, this is the most awkward type of failure. There is no exception, no alert fires, and the logs are clean. The only way to learn about the problem is from the customer, if they haven't already left.

Where silence usually hides

This symptom has several typical causes. It is unknown which one applied here, but all of them produce the same picture: everything is green, and there is no reply.

• A 200 code means receipt, not delivery. Messaging APIs usually accept a message into a queue and report its delivery outcome later, through separate status webhooks.
• Empty or broken model output. An LLM can return an empty string, truncated JSON, or a service marker instead of text. To n8n this is valid data, and the send node runs as normal.
• Platform restrictions. Messengers have reply windows, template requirements, and moderation rules. A message can be accepted but never shown to the user.
• A wrong field in an expression. If the send node pulls its text from a path that does not exist in the data, n8n substitutes an empty value without raising an error.
• Race conditions and duplicates. Repeated webhooks, parallel runs, and shared conversation memory can overwrite a reply before it goes out.

All of these have one thing in common: success is measured on the infrastructure side, not on the human side.

How to catch these bugs

The first thing to do is add a content check before sending. A simple filter node that rejects an empty string, text that is too short, or text containing service markers closes off an entire class of errors. If the check fails, the workflow should go down an error branch rather than continue along the green path.

Second: don't treat 200 OK as the end. Delivery statuses from webhooks need to be stored and matched to outgoing messages by ID. Any message without a "delivered" confirmation after a set time becomes an incident.

Third: introduce a conversation-level metric. The share of incoming messages that received no non-empty reply within N seconds shows the agent's real condition better than statistics on successful runs. It also provides the basis for an alert in the team's work chat.

Fourth: set up an Error Workflow in n8n and a separate fallback. If the agent goes silent, the customer receives a short "We've received your message and will reply shortly," and an operator gets a notification with the conversation context.

Fifth: run synthetic conversations. A regular test account that messages the agent and waits for a reply catches silence before real people do. For a business where a bot chat is the main sales or support channel, such a check costs less than a single lost lead.

The Habr story illustrates a general lesson of operating agents: reliability is defined by what the user saw, not by what the orchestrator's dashboard showed.