Error handling in n8n is not optional
Most n8n workflows break silently. A missing error branch means failed enrichment runs, missed signals, and CRM records that never got updated.
The default n8n behaviour when a node fails is to stop the workflow and log an error. If you’re not watching the execution log, you’ll never know. The sequence didn’t fire. The record didn’t update. The signal got dropped.
Every production workflow I build has three things the default template doesn’t:
An error workflow. n8n lets you set a workflow to trigger on failure. Mine writes the failed execution ID, the node that failed, and the input data to a dedicated error log in Airtable or a Slack channel. If I’m not seeing error alerts, the workflow is running clean.
Null checks before every enrichment write. Clay returns null for fields it couldn’t find. If your n8n workflow tries to write a null value to a required CRM field, HubSpot rejects the whole record update, not just the null field. Check for null explicitly on every enrichment output before writing to CRM.
Retry logic on rate limit errors. Clay, HubSpot, and Salesforce all have API rate limits. Build a Wait node with exponential backoff after any HTTP node that hits an external API. The pattern: catch a 429 response, wait 30 seconds, retry. If it fails three times, route to the error log.
The extra 30 minutes to wire up error handling saves hours of debugging three months later when a workflow has been running in production and nobody noticed it’s been silently failing for two weeks.
One more thing: log your workflow runs, not just your errors. A simple counter (records processed, records enriched, records skipped) tells you whether the workflow is running at the expected volume. A workflow can succeed technically and still be doing nothing useful.