n8n saved your change and production is running the old one

The bug report that is not a bug

Somebody fixes a workflow, watches it run correctly in the editor, and closes the tab. The next morning the same failure is in the execution list, with the same error, from the version they thought they had replaced.

Nothing is broken. The editor was showing the truth about the draft, the execution list was showing the truth about production, and those are two different things that n8n keeps deliberately apart.

What autosave actually saves

Everything, immediately, into a draft:

n8n auto saves your workflow while you're editing. When you're ready to put the workflow into production, publish your workflow. This approach prevents accidental production changes while enabling safe iteration and review.

• Save and publish workflows, n8n Docs

And it is fast enough to feel final:

Changes save automatically as you edit, typically within 1 to 5 seconds. No manual save button is required. All edits remain in draft until you publish.

• Save and publish workflows, n8n Docs

This is a good design decision with one expensive side effect. Every habit built on the old muscle memory - edit, see it save, consider it done - now stops one step short, and stops silently. There is no unsaved-changes warning to catch you, because nothing is unsaved.

What production runs instead

The published version, pinned:

Publishing makes your workflow live and locks it to a specific version. Production executions will use this published version, not your latest edits.

• Save and publish workflows, n8n Docs

Said again, elsewhere on the same page, because it is the thing people get wrong:

Each time you make a change to a workflow, n8n autosaves those changes to a new version of the workflow. These saved versions go live in production only when you publish the workflow after the changes.

• Save and publish workflows, n8n Docs

Production executions always point to the currently published version.

• Save and publish workflows, n8n Docs

So a workflow can be simultaneously fixed and broken, and both statements are accurate: fixed in the version you are looking at, broken in the version that runs at 3am.

The exception nobody expects

One category of change goes live on its own:

If you only update workflow settings, n8n will re-publish the version without requiring you to take any action.

• Save and publish workflows, n8n Docs

The word carrying the weight is only. A session where the settings panel is the one thing you touched re-publishes itself. A session where you changed a setting and also moved a node does not qualify, so nothing goes live until you publish.

How do you tell which state a workflow is in?

The header button is the indicator, and n8n documents what each state means:

When you open a workflow with no publishable changes, the Publish button is disabled.

• Save and publish workflows, n8n Docs

The docs list six button states. The one that matters here is described as:

The workflow is published, but you've made changes since the last publish that haven't gone live yet.

• Save and publish workflows, n8n Docs

An active Publish button means the version in front of you is not the version running. That is the entire check, and it takes a second - the difficulty is that it requires opening the workflow, which is exactly what nobody does for the twenty workflows they are not currently editing.

There is a second state worth knowing, because it looks like the same thing and is not:

The workflow is published, but there are errors in your recent changes that need to be fixed before you can publish again.

• Save and publish workflows, n8n Docs

Here the draft cannot be published until the errors are cleared, so the old version keeps running while the editor shows work that will not go live.

Why does this hit teams harder than individuals?

Because n8n serialises editing, and the lock is invisible from outside the workflow:

Only one person can edit a workflow at a time. If someone else is currently editing:

You see the workflow in read-only mode

The edit lock releases when they stop editing or become inactive

You can then take over editing with the latest changes

• Save and publish workflows, n8n Docs

The failure this produces is mundane and hard to see: one person edits and leaves without publishing, a second person takes over the lock later and publishes, and now a change nobody reviewed goes to production attached to somebody else's publish action. The version history records what shipped, but not who intended each part of it.

What to do about it, in order

1. Before debugging anything, check the Publish button. Active means the editor and production disagree. Do this before reading a single node.
2. Compare the execution against the published version, not the canvas. Version history is where the running behaviour lives.
3. Publish deliberately when the change is finished, even when it looks trivial - and leave it unpublished on purpose when it is not, since that is what the draft is for. A workflow that runs wrong for a week is often one somebody fixed correctly and then closed the tab on.
4. Name the versions that matter, if your plan has them. Named versions are protected from automatic version history pruning, so they persist indefinitely - a version called before invoice rewrite is worth more than a UUID when you need to go back in three weeks. Check your plan first: the docs list named versions on n8n Cloud Pro and Enterprise, and on self-hosted Enterprise.
5. Know which kind of session you just had. If the settings panel was the only thing you touched, production already has the change. If you touched anything else as well, nothing is live until you publish - the setting included.
6. When handing a workflow to somebody else, publish or explicitly say you did not. The lock will release on its own, and the next person cannot see what you intended.

How this interacts with silent failure

The two failures compound in a specific way worth naming.

A workflow whose fix was never published keeps failing exactly as it did before. If its failures are loud, you will see them in the execution list. If the thing that broke was the trigger, there are no executions at all, and now two silences stack: nothing runs, and nothing tells you that the fix you wrote is still sitting in a draft.

That combination is the one where a month passes. It is also why the check that catches it is not an error alert but a count of expected runs, and why a trigger that stopped firing deserves its own diagnosis rather than another look at the nodes.

When this is a job to hand over

If you have a handful of workflows and you know which ones you touched, the answer is a habit, not a project: check the button, publish on purpose.

It stops being that when nobody can say which of thirty workflows are running a version that matches their canvas, when a workflow has been failing long enough that the data behind it needs reconciling, or when settings-level changes went live during experimentation and nobody knows which. Sorting out which version of what is actually in production, and reconciling what ran while it was wrong, is scoped work with a known shape and a known price, and that is what Fix S and M are for.

Sources

• Save and publish workflows - n8n Docs, read 18 August 2026. Autosave to draft within 1 to 5 seconds, publishing locking a version, production executions using the published version, settings-only updates re-publishing without action, and the only that scopes it, Publish button states, the single-editor lock, and named versions being protected from pruning on the plans that offer them.