The reminder API accepted the command. The next node failed while writing “complete.” n8n now shows a red execution, but the customer may already have received the email. Pressing retry is not recovery until someone can answer that question.
Reconstruct the partial-failure timeline
- The product decides a reminder is due and emits an event.
- n8n receives the event and calls the product command endpoint.
- The command endpoint may create the customer-facing effect.
- A later node records completion or updates another system.
- If step four fails, the execution state and customer state disagree.
The workflow needs a shared identifier that lets an operator search both states. That identifier does not magically prevent duplicates. Deduplication and idempotency belong in durable product storage and must survive replay, concurrent delivery and failure after effect.
Write the contract before drawing nodes
Illustrative fictional job: an invoice.reminder_requested event asks a product API to send one payment reminder. n8n transports and observes the job; it does not decide whether money is owed.
| Event identity | A durable event_id shared by the producer, n8n execution, command record and alert. |
|---|---|
| Effect owner | The product API owns reminder eligibility, recipient policy and the reminder record. |
| Repeat rule | The product API defines whether the same identifier may be submitted again and what response proves prior completion. |
| Evidence | A recorded effect ID—not a green node alone—shows that the customer-facing action exists. |
| Data boundary | The event carries identifiers needed for the command, not invoice notes, card data or a full customer history. |
| Human owner | A named operator can pause, inspect, reconcile and close a failed event. |
Pseudo-workflow: keep detection separate from recovery
Webhook: receive invoice.reminder_requested
authenticate request
require event_id, account_id, invoice_id, requested_at
reject unknown event type with Stop And Error
Reserve event in product API
same event_id on every attempt
duplicate response -> stop and inspect existing effect
invalid or forbidden response -> stop; do not retry unchanged input
transient response -> retry only if this operation is safe to repeat
Request reminder from product API
send event_id as the API's documented idempotency key
require a durable reminder_id or prior-effect response
Record completion
attach reminder_id to event_id
Error Workflow
include event_id, workflow/execution identity and failed node
exclude secrets and unnecessary customer content
route to a named operatorThe response categories above are placeholders, not claims about a real endpoint. A real implementation must copy the called API’s status contract and verify how it behaves when two requests arrive together.
Use n8n’s mechanisms without confusing them with reliability
Official n8n documentation observed on 28 July 2026 describes Error Workflows beginning with an Error Trigger, Stop And Error, HTTP Request Retry on Fail, execution saving, timeouts, production-data redaction and manual retry of failed executions. Availability and limits may depend on edition, plan and settings. Recheck these capabilities whenever the edition, plan, version or environment changes.
An Error Workflow exposes failure information. Retry on Fail repeats a node. Saved executions preserve an investigation surface. None of them proves that the downstream action is safe to repeat.
Give each failure a different recovery
| Failure | Question before action | Recovery path to test |
|---|---|---|
| Malformed event | Which producer or schema version created it? | Fix the producer; replay only after validation. |
| Duplicate event ID | Does a reservation or effect already exist? | Reconcile the existing record; do not resend for a green run. |
| Expired credential | Did any privileged operation run before rejection? | Repair scope and credential; replay the saved event deliberately. |
| Rate limit or temporary dependency error | Is the called operation repeat-safe with the same ID? | Use bounded delay only under that contract. |
| Effect happened; completion write failed | Can the effect be found by event ID? | Repair completion state without repeating the effect. |
| Alert failed | Where else can unacknowledged failures be found? | Use execution monitoring and repair the secondary alert path. |
Run a drill card, not a confidence check
In a non-production environment, inject a duplicate, malformed payload, expired credential, simulated transient failure and failure after the effect but before completion. Capture the workflow version, settings, execution ID, product event record, effect record, alert and operator decision for each case.
Do not claim the drill succeeded until it has been executed and its evidence reviewed. If the operator cannot determine whether the customer-facing effect occurred, the immediate decision is to keep that effect out of the workflow.
The six-line recovery runbook
- Identify: copy the event ID, execution ID, workflow version and failed node.
- Check effect: search the product’s durable event and reminder records before retrying.
- Classify: invalid, duplicate, permission, transient, partial completion or unknown.
- Contain: pause the trigger when repeated executions could contact customers incorrectly.
- Recover: repair the cause and replay only under the API’s tested repeat contract.
- Close: verify one intended effect, reconcile state and record the corrective change.
Reserve the workflow for recoverable side effects
Ignore a gallery of seven clever workflows. Ignore a green happy-path execution. Ignore “exactly once” language unless you can demonstrate the storage and transaction boundaries that support it. One recoverable reminder flow is more valuable than many automations whose effects cannot be traced.
The retry rule an operator can use
The worst retry button is the one clicked to clear a red dashboard. “Run again” is not a recovery decision. Find the customer-facing effect first, then choose the smallest action that repairs the state around it.
Automate only after the effect is traceable
Do not automate the customer-facing reminder until the same event ID reaches the execution, product record, effect and alert—and a drill proves an operator can reconcile partial failure. Until then, keep the reminder manual or make n8n prepare a review queue rather than send it.
Documentation to revalidate
- n8n, Error handling, observed 28 July 2026; confirm the current behaviour on the version and execution mode you operate.
- n8n, HTTP Request common issues, observed 28 July 2026; repeat safety still belongs to the called API.
- n8n, Workflow settings, observed 28 July 2026; verify edition, plan and retention.
- n8n, Workflow executions, observed 28 July 2026; history behaviour depends on workflow and retention settings.