Found a bug in my production workflow that never once threw an error — because it wasn't failing, it was just wrong
I've been running a lead-capture pipeline in n8n for a real B2B operation (self-hosted, webhook → validation → CRM/Sheets/Telegram). It's been "succeeding" on every execution for weeks. Green checkmark, every single run.
Turns out one of the Airtable field mappings had phone pointed at {{ $json.body.segment }} instead of {{ $json.body.phone }}. So every CRM record's phone number was silently getting overwritten with the segment value — "hotel," "restaurant," whatever the person picked on the form. Not blank, not null, not an error. Just confidently wrong data, written cleanly, every time.
The reason it never surfaced in the execution log is obvious in hindsight: n8n (like most tools) reports success based on whether the node ran, not whether the data going in was correct. A field-mapping typo is invisible to error monitoring by definition — there's no exception to catch, no failed HTTP call, nothing for an Error Trigger workflow to hook into.
What actually caught it was dumb luck plus a redundant design choice — I'd been logging the same raw payload to Google Sheets in parallel as a backup, mapped independently from the Airtable node. When I cross-checked the two during an unrelated audit, the phone numbers didn't match. That mismatch was the only signal.
Since then I've started treating "parallel logging to a second, independently-mapped destination" as a real debugging tool, not just redundancy — if two branches built from the same source data ever disagree, one of them has a mapping bug, and you'd never know which without the second copy.
Anyone else building n8n pipelines run into this class of bug — logic/mapping errors that never trip error handling because there's nothing to catch? Curious what people do to audit for correctness rather than just uptime, especially on workflows with a lot of field remapping (Set/Code nodes feeding into CRM writes).