Building a 24/7 error handling system: what happens when your automation breaks at 3am.

Every automation will fail. This is not pessimism, it is statistics. The external APIs you depend on will return unexpected errors. The data you process will occasionally arrive malformed. The webhook you expect will not arrive. The n8n instance will restart during a long-running execution. The question is not whether your automation will fail; it is whether when it fails, you know about it before your business does.

Silent failures are the most expensive failures in workflow automation. A silent failure is one where the automation stops working, stops creating records, stops sending confirmations, stops routing leads, but generates no alert, no error notification, and no visible indication that anything has gone wrong. The business continues operating under the assumption that the automation is running. Days or weeks later, someone notices that the CRM has not been updated, or that clients have not received their onboarding emails, or that a payment has not been followed up. By then, the damage, lost leads, unhappy clients, missed revenue, has already occurred.

The PURIST approach to error handling in n8n is layered. The first layer is node-level error routing: every node in every production workflow has an error route defined. When a node fails, the error route triggers rather than terminating the workflow silently. The error route captures the error message, the node name, the input data that caused the failure, and the workflow execution ID, and routes this information to a centralized error logging workflow.

The second layer is the centralized error logging workflow. This single workflow receives error events from every other workflow in the system, writes them to a structured error log (we use a Postgres table with columns for workflow_name, node_name, error_type, error_message, input_payload, timestamp, and resolved status), and sends a Slack notification to the operations channel with the relevant details. The Slack notification uses a structured format: workflow name, failure time, error type, and a direct link to the n8n execution log for debugging. A P1 error, one affecting a payment flow, a patient booking, or a client-facing communication, triggers both a Slack alert and an SMS to the on-call engineer.

The third layer is health monitoring, proactive checks that detect not just failures but degraded performance. A monitoring workflow runs every 15 minutes and queries the error log database for any workflow that has had an error rate above 5% in the past hour, any workflow that has not executed in its expected interval (flagging stuck or stalled workflows), and any workflow processing time that has exceeded twice its historical average (flagging performance degradation). These health checks catch the failure modes that node-level error routing misses, the workflow that is running but slowly, the workflow that is not running at all because its trigger stopped firing.

The fourth layer is the recovery runbook. Every production workflow has a documented recovery procedure: what does a human do when this workflow fails? Where is the data that needs to be manually processed? What is the rollback procedure? This documentation is not theoretical, we test recovery procedures quarterly against intentionally triggered failures. The automation that can be recovered in 10 minutes by anyone on the team is the automation that survives a 3am failure without consequences. The automation that only the original builder knows how to fix is an operational liability.