A silent failure is the most dangerous kind of failure. By implementing dedicated error-handling architectures, you ensure that every crash is logged, every admin is notified, and every piece of data is recoverable.
1The Global Safety Net
By default, when a node fails in n8n, the entire workflow stops and the error is logged silently. You might not find out for hours. The Global Error Trigger fixes this: it's a dedicated secondary workflow that n8n automatically activates whenever any other workflow fails. You configure it once and it becomes your system-wide incident response system.
The Error Trigger receives the full context: which workflow failed, which node caused it, the error message, the timestamp, and the data that was being processed when it crashed. You can use this metadata to send a formatted Slack or Discord alert with everything your team needs to diagnose the issue — no manual log-digging required.
This architecture is the difference between a hobby project and a production system. Keep your main workflows clean of error logic. Centralize it all in the error workflow.
// Error Trigger payload (auto-received)
{
"workflow": { "name": "Lead Sync" },
"execution": {
"id": "exec_abc123",
"startedAt": "2024-03-15T09:00:00Z"
},
"error": {
"message": "Connection refused",
"node": { "name": "CRM Upsert" }
}
}
// Error workflow -> Slack alert
"[ALERT] Lead Sync failed at CRM Upsert: Connection refused"2Graceful Degradation
Not all errors are fatal. Graceful Degradation is the pattern of letting a workflow continue even when a non-critical step fails. The tool in n8n is the 'On Error: Continue' setting on individual nodes. Instead of halting execution, the failed node outputs an error object, and your workflow keeps running.
The key is pairing this with an IF node immediately after: check whether the previous node succeeded or errored. If it errored, route to a fallback (log a warning, send a low-priority alert, skip the optional step). If it succeeded, continue the happy path. This is the visual equivalent of a try/catch block.
Use this for optional, non-blocking steps: Slack notifications, analytics pings, cache updates. Never use 'On Error: Continue' on nodes that write critical data — if a database write fails silently, you've lost data without knowing it.
// Node settings (n8n UI equivalent)
// Slack: Send Notification
// On Error: Continue <-- enabled
// IF node after Slack:
if ($node['Slack'].error) {
// Output: Error path
-> Log warning to Google Sheets
} else {
// Output: Success path
-> Continue to next step
}
// Critical DB write (never use 'continue' here)
// Postgres: Upsert Contact
// On Error: Stop <-- default, keep it3Dead Letter Queues
When a data-processing step fails — a CRM upsert, an email send, an API call — the data that caused the failure shouldn't just disappear. A Dead Letter Queue (DLQ) is a holding area where failed items are stored for later analysis and re-processing.
In n8n, the simplest DLQ is a Google Sheet or a database table with columns: timestamp, workflow, node, error_message, raw_data. When your Error Trigger fires or an 'On Error: Continue' branch catches a failure, write the failing item to this table. Now you have a complete audit trail.
When the root cause is fixed (the API is back online, the schema mismatch is resolved), you can pull those rows back from the DLQ and re-run them through the same workflow. Zero data loss. This is the pattern that separates systems your customers can trust from ones that quietly drop records.
// Dead letter queue write (on error branch)
const failedItem = {
timestamp: new Date().toISOString(),
workflow: 'Lead Enrichment',
node: 'Clearbit API',
error: errorMessage,
raw_data: JSON.stringify($input.item.json)
};
// n8n: Google Sheets node
// Operation: Append Row
// Sheet: 'Dead Letter Queue'
// Data: failedItem