Why Does My n8n Workflow Still Run the Old Version After I Edit It?

If an n8n workflow still runs an old version after you edit it, first check whether the changes have been published, rather than assuming they were not saved. n8n saves edits automatically, typically within one to five seconds, without a manual Save button. Production executions, however, use the published version, not your latest edits. The canvas can therefore show the latest draft while a real trigger still runs the previously published version.

Consider a hypothetical example: a node originally outputs sales-old, and you change it to output sales-new. A manual test shows sales-new, but a new production execution still produces sales-old. Before changing the code again, check the publishing status. SHMLANG recommends starting with that distinction.

The manual test shows the new value. What should I check first?

Check the following in order:

1. Look for unpublished changes in the current workflow. Having published the workflow before does not mean that subsequent edits are live.
2. Confirm that publishing has finished. Publishing is asynchronous: n8n applies trigger changes in the background, and the button shows Publishing until the result is confirmed. This status persists after a page refresh because it is stored on the server.
3. Use a new event sent after publishing finishes to identify the corresponding production execution, rather than inspecting an old run.

Distinguish a partial publication from a failed publication. With a partial publication, the new version has been published, but at least one trigger failed to activate; the workflow continues to run the triggers that did activate. With a failed publication, none of the triggers activated, so the workflow is not running. In either case, inspect the interface message and check whether the trigger you depend on is active before deciding whether to publish again.

How do I confirm that this execution used the new changes?

Continue with the hypothetical example. Prepare controlled test data containing no real customer information, with an event identifier such as eventId=version-check-001. Run a manual test and look for sales-new. This proves only that the value observed in that test is new. Manual runs can use pinned data, so that observation does not prove the entire draft logic is correct, let alone that production has been updated.

After publishing, wait for the interface to confirm completion, then send an identifiable controlled event to the trigger entry point for that published workflow, such as eventId=version-check-002. Use controlled test data and controlled downstream targets only; do not operate on real customers or live business targets. Open the workflow’s Executions tab, find the production execution by its time, verify eventId in the input data, and inspect the output of the node you changed.

If that record contains sales-new, this production execution has used the new change. If it still contains sales-old, continue checking rather than jumping to a conclusion. Production executions do not display their execution flow directly on the editor canvas as manual runs do. Inspect the Executions tab instead; whether records are available also depends on the workflow’s execution-saving settings.

Why does the result still look old after publishing?

First confirm that you are looking at the correct execution. Check three things: whether the execution belongs to the workflow and instance you actually edited, whether its time is after publishing completed, and whether its event identifier matches the event you just sent.

Two kinds of history are easy to confuse. Workflow history contains saved workflow configurations, allowing you to view and restore earlier versions. Execution history records workflow runs and the results of those runs. A historical configuration tells you which nodes and parameters were saved; an execution record tells you what a particular run actually output. Neither being old is sufficient to conclude that the output was sales-old. Workflow history is not execution output, and an entry in the executions list is not proof that a particular version is live.

Frequently asked questions

Does restoring an old version also roll production back?

Not automatically. Restoring a version replaces the current workflow with the selected version so you can edit or compare it. Production executions still use the currently published version. To make the restored configuration live, review it and publish it again.

Can pinned data affect a manual test?

Yes. In a manual execution, you can pin a node’s output. Later manual runs substitute that saved output instead of executing the pinned node. Production executions ignore all pinned data. If a manual test always looks correct, check whether it uses pinned data: the saved output may conceal how the node actually behaves when executed.

You do not need to identify every possible cause at once. Start with publishing status, then use a new, identifiable event to check the changed node’s output. If the old value remains, verify the actual workflow, instance, and execution time.

Build a first website-inquiry workflow with three nodes