Error Handling and Monitoring

The most dangerous automation is one that appears to be working but is silently failing or producing wrong results. This is far more common than outright crashes. Understanding failure modes is critical to building production-ready automations. Common failure modes: API rate limits cause requests to fail after the first 100 — subsequent executions silently skip records. A third-party API changes its response format — your downstream data becomes malformed without any error thrown. A webhook URL becomes stale because you restarted n8n on a new server — form submissions stop being captured. A Google OAuth token expires — all Google Workspace nodes start failing. N8n's execution log is your first line of defense. Every workflow execution is logged with its status (success/error), execution time, and the data at each node. Check this log regularly during the first week after launching a new workflow. Look for: consistently slow executions (upstream API is struggling), high error rates, and mismatched input/output record counts. Beyond the built-in log, you need active alerting. Set up an Error Workflow in n8n — this is a special workflow that runs whenever any other workflow throws an uncaught error. In the Error Workflow, send a Slack message or email with the workflow name, the error message, and a link to the failed execution. You'll know about failures within seconds. For critical workflows (payment processing, customer-facing automations), add explicit assertion nodes — IF conditions that check that expected data is present before proceeding, and route failures to a dedicated error-handling path.

Not all errors are permanent. A network timeout, a brief API outage, a rate limit hit — these are transient errors that will succeed if you simply try again. Hard-coding retry logic into your workflows makes them dramatically more resilient. N8n's HTTP Request node has built-in retry options: you can configure it to retry on failure up to N times with a delay between attempts. Enable this for all external API calls. Start with 3 retries, 1000ms delay, exponential backoff (each retry waits longer than the last). For more complex retry scenarios, use the Loop node to implement custom retry logic with explicit conditions. Check the response, decide whether to retry, track retry count, fail after max retries with an informative error message. Idempotency is related and equally important. When your automation retries, will running the same action twice cause problems? Sending the same email twice is bad. Creating a duplicate CRM record is bad. Inserting a duplicate row in a database is bad. Design your automations to be idempotent: check if the record already exists before creating it, use 'upsert' operations where available, and store a record of what's been processed (a simple Google Sheet or database table works fine). Finally, set up a dead letter system for permanently failed records. When an item fails after max retries, write it to a 'Failed Items' sheet or table with the error message and timestamp. Review this list weekly. Permanently failed items are often signals of systematic problems — a bad data format, a deprecated API, or a changed field name.