n8n in production: errors, retries and alerts that actually work

An n8n workflow that works in a demo is not ready for production. In production there are APIs returning 500s, expiring tokens, rate limits, incomplete data and overlapping executions. The difference between a useful automation and a source of incidents is how those cases are handled.

This is the checklist we use before activating a workflow that touches business data.

The happy path is not production

The first version of a workflow is usually tested with a perfect record: every field complete, the API returns 200 and nobody else is using the system. In production, the same workflow receives an email with no domain, an order with an amount in another currency or a response that takes thirty seconds.

Before activating, ask yourself:

• What happens if the external API fails?
• What happens if the workflow runs twice with the same data?
• What happens if volume multiplies by ten?
• How do I find out that something broke?

If there is no answer to all four, the workflow is still a prototype.

Idempotency: the property that prevents duplicates

A workflow is idempotent when running it twice with the same input produces the same result as running it once. It is the most important defence against retries and duplicate executions.

In practice:

• Use a unique key per event (order ID, email + date, message ID).
• Check whether that key has already been processed before creating a record.
• Store the result of the operation, not just the fact that you attempted it.
• If the external system allows it, use “upsert” operations instead of “create”.

Without idempotency, an automatic retry can send the same invoice twice. With idempotency, you can retry with confidence.

Retries with judgement

Not every error deserves a retry. A 401 for invalid credentials will not fix itself by retrying; a 429 for rate limiting will. The policy should distinguish:

• Transient errors: retry with exponential backoff and a maximum number of attempts.
• Validation errors: do not retry; send to a review queue.
• Authentication errors: alert and stop the workflow.
• Business errors: log and decide according to the process rule.

In n8n you can configure retries per node and use a dedicated error workflow. The important thing is that the retry does not repeat side effects that were already applied.

Alerts people do not ignore

An alert for every error produces fatigue and, sooner or later, someone silences it. Better to alert on patterns:

• three consecutive failures of the same workflow;
• an execution that exceeds the expected maximum duration;
• a workflow that does not run in the expected window;
• a queue of pending items growing above a threshold;
• an error rate above normal in an hour.

The alert should include the workflow name, the specific execution, the error and a link to open it. If the team has to search for context, the alert arrives too late.

Observability: logs, metrics and traces

n8n keeps an execution history, but that is not always enough. For critical processes, send events to a central system:

• start and end of each execution;
• correlation ID with the source system;
• duration and number of retries;
• result and failure reason;
• minimal data to reproduce the problem, without secrets.

With that you can answer “what happened to order 1234?” without opening five tools.

A recovery plan

Workflows break. The question is how long it takes you to recover and whether you lose data along the way.

For every critical automation you should have:

1. A procedure to pause the workflow without losing events.
2. A queue or table where pending events are stored.
3. A command or workflow to reprocess a specific batch.
4. An owner responsible for reviewing the alert.
5. A periodic recovery test.

If the plan only exists in the head of the person who built the workflow, it is not a plan.

Checklist before activating

• □ The workflow has an idempotency key.
• □ Retries distinguish transient from permanent errors.
• □ There is an error workflow that logs the failure and alerts.
• □ Credentials are outside the workflow and rotated.
• □ The external API limits are documented.
• □ There is a staging environment with representative data.
• □ There are pattern-based metrics and alerts, not noise.
• □ Someone knows how to reprocess a failed batch.
• □ Cost and volume are measured.

At Coderwebs we design and implement these automations as part of n8n, including the API integration layer and monitoring. If the workflow connects critical systems, we also review the API integration so errors do not propagate silently.

Conclusion

Automation does not end when the workflow works once. It starts when it fails and the system knows what to do. Idempotency, thoughtful retries, pattern-based alerts and a recovery plan are what separate a demo from a real operation.