Short answer: Start an error workflow with the Error Trigger. Record the failed workflow, execution, node, and message. Notify an owner. Retry only when the operation is safe to repeat.

What does the Error Trigger provide?

The Error Trigger starts a separate workflow when another workflow fails. The event can include the workflow name, execution details, failed node, and error message. Use those fields in the first logging or notification node.

Keep the error workflow small. It should still run when the main workflow has a broken branch, missing credential, or invalid input. Avoid adding the same complex dependency that caused the original failure.

Which details belong in an alert?

Include the workflow name, execution ID, failed node, timestamp, and a short error message. Add the input identifier when it is safe to include. Do not send access tokens, full request headers, or sensitive payloads to a chat channel.

Link the alert to the n8n execution when your deployment permits it. The recipient should be able to find the failed run without searching by memory or title.

When is a retry safe?

Retry a read request or a rate-limited call when the operation is designed to repeat. Be careful with payments, ticket creation, email delivery, and other actions that can create duplicates. Use an idempotency key when the external API supports one.

Set a small retry count and a delay. Record each attempt. Stop after the limit and escalate the original error instead of creating an endless retry loop.

How should the error workflow be tested?

Create a test branch that fails on a known value. Confirm that the Error Trigger receives the event. Check the alert fields and the stored execution ID. Then test a timeout or authentication failure, because those errors often need different handling.

Use the execution debugging guide to inspect the original run. Use an IF or Switch branch when the error message needs separate handling for temporary and permanent failures.