The silent failure: when your n8n workflow succeeds but does nothing

Execution shows ✓, no errors — and nothing happened. Four modes, one missing layer, and the exact node pattern to fix it on n8n 1.77.1.

The 4 modes

1. The no-items branch that silently exits

An IF node routes on whether a value exists. If it doesn't, the false branch ends with no error. You find out days later when someone asks why the automation didn't run.

Fix: Every "should never happen" branch ends with a Slack/email alert or a Stop And Error node. Silent exits are bugs.

2. The HTTP Request that returns 200 but the API failed

Many APIs return 200 OK with {"success": false} in the body. n8n doesn't know — it just passes the response downstream.

Fix: After any HTTP Request, add a Filter/IF on {{$json.success}} (or the API's error field) and route failures to an error lane.

3. The Set node that overwrites items you needed

Set in "replace" mode drops fields you didn't re-declare. Downstream nodes then operate on empty items and silently produce nothing.

Fix: Use Set in "keep only set" = false, or merge back the original items before the next step.

4. The missing reconciliation layer

The workflow sent 12 but the target contains 11. No count, no baseline, no expectation would have caught it — because nothing on the sender side was wrong.

Fix: Reconcile against the destination: after creating the row/tag/message, re-read the target by ID and assert count == expected.

The pattern that survives the engine lying to itself

HTTP Request (Always Output Data: true, Retry 3x 1s→5s)
  → IF: {{ $json.success }} === false  →  error lane (Slack/email/Stop And Error)
  → HTTP Request (read-back): GET /items/{id}
  → IF: count != sent                  →  same error lane + dead-letter queue

This catches both the "200 with error body" case and the case where the engine correctly sent 12 but the target only holds 11. My production stack runs this on myn8n-automation.org (n8n 1.77.1, VPS sf-vps, Docker + SSL) and the guides at webhook-not-firing / api-timeout / postgres-ssh-hang cover the neighboring failure modes with the same node diff.

Want it diagnosed in your workflow?

This is the exact failure I productized as a $15 diagnostic — repro the silent branch in your workflow and ship the precise respond/Filter/IF diff plus retry/idempotency/backoff spec in ~4 hours.

Get the $15 Diagnostic — 4h Delivery → Or get the 8-node Weekly Workflow ($29, instant file) →

Same checkout: crypto (Base USDC 0xF0A66B2d45f07b48f4D08a3daEc84e43139D8aDc) · Card/Apple Pay via Gumroad · Saudi Rajhi SA098... / STC 0574450435 · Delivery tracked in dispatch log.