n8n error handling: capture failures before adding retries

n8n workflows can fail partway through, leaving partial output and an unclear state, and the remote service may have already processed a request whose response was lost. Immediately retrying the whole run can cause duplicate emails or records, so the guidance is to make failures visible first and then decide which operations are actually safe to retry. The approach uses two native n8n nodes, Error Trigger and Stop And Error, and stresses attaching a stable business key such as an order ID so repeated attempts can be tracked across runs. An independent error workflow should capture the execution reference and send alerts to an approved channel, with reporting kept separate from retry logic. The article also recommends capping retry attempts with persistent counters, reconciling remote state for ambiguous writes, and escalating to manual review when no lookup is available.