Choose the workflow version before retrying a failed n8n execution

What changed in 2.44.0?

n8n 2.44.0, released on October 13, 2026, includes an execution-card retry menu update. Its official release page was marked as a pre-release when checked on October 19. Check your installed version and interface before upgrading a production environment for this change.

The change adjusts menu alignment and button width and adds a short title and description to each option. It does not announce new retry scope or duplicate prevention. External results still need a separate check.

How do you choose the current or original version?

The execution list has two choices under Retry execution. These are the short names added in the 2.44.0 change alongside the longer names in the documentation.

Sources: the official change and execution documentation, checked on October 19, 2026. Both options use previous execution data. Choosing the saved workflow does not refresh the input.

Failed execution data → selected workflow version → check the retry result

If the input was wrong, reconsider retrying with that data. Keep a new execution with fresh data distinct from a retry in your records.

How do you load data while fixing the cause?

Open the workflow's Executions tab and select Debug in editor for a failed execution. For a successful execution, use Copy to editor. n8n copies the previous execution data into the current workflow and pins it in the first node.

The debugging documentation lists all n8n Cloud plans and registered Community, Business, and Enterprise self-hosted editions. You need saved execution data to compare. Check the saving settings if the list is empty.

Pinned data lets you reuse input during development. It can reduce fresh-data calls from the pinned node, but it does not turn every downstream send or update into a simulated action. Check whether those steps still connect to real accounts and switch them to test destinations. Data pinning is unavailable in production executions.

What should you check in the external service first?

If the failed node sends email or changes data, look for the result in the service's sent folder or change history. Avoid repeating the request while its result is uncertain. Use this operator checklist before retrying.

1. Record the failed execution ID and node.
2. Compare external results and request IDs for the same target and time.
3. Once you know what happened, decide what remains and what to rerun.
4. If you changed the configuration, check the saved workflow and select the matching retry option.

If the service supports an idempotency key, check its contract too. The workflow-version choice in n8n does not itself resolve duplicate processing in an external service.

What records should you keep for the next failure?

The workflow menu's Settings includes options to save failed production executions and per-node progress. The documentation says saving progress allows resuming from the stopped point after an error and may increase latency. Also decide how much input and output data to retain.

Keep the original execution ID, selected version, configuration changes, and external result in the incident record. Make those four values easy for the next operator to find before sending the request again.

Sources: n8n 2.44.0, retry menu change, all executions, debug previous executions, data pinning, workflow settings. Checked on October 19, 2026.