n8n makes it deceptively easy to wire up a working automation in an afternoon — and deceptively easy to end up with a workflow that fails silently in production three weeks later. Here are five patterns that consistently separate "works in the demo" from "actually reliable."
1. Never trust a single HTTP node without error output handling
By default, a failed HTTP Request node just stops the workflow (or worse, continues with an empty item if you're not careful with "Continue on Fail"). Route error outputs to a dedicated logging/alerting branch — Slack, email, or a database table — so failures are visible instead of just... missing data downstream.
2. Idempotency keys for anything that touches money, messages, or records
If a workflow re-runs (webhook retry, manual re-trigger, execution recovery after a crash), you don't want to double-charge a customer or send a WhatsApp message twice. Store an idempotency key (a request ID, message ID, or hash of the payload) and check it before executing the side-effect step.
