5. Changing a workflow that's running

Overview

By the end of this lesson you'll know how to do something almost nobody teaches and that you do every time you improve a production workflow: modify something that thousands of daily executions depend on, without breaking it in the attempt. You'll understand n8n 2.0's draft-and-publish model —what saving is and what publishing is, and why they're different things— what happens to the executions running at the exact moment you publish, how to test a change without exposing it, how to roll back with the version history when something went wrong, and why Friday at six in the afternoon is not the time to publish anything.

This matters because the work of operating is, to a large degree, the work of changing things that are already running. Everything the previous lessons taught you to demand of a workflow —adding error handling, adjusting a credential, correcting a checklist item— implies modifying it. And a production workflow isn't a document you edit calmly: it's a running engine. Changing a part while it spins has its own rules, and not knowing them is how many people learned: publishing a "small" change on a Friday afternoon and spending the whole weekend putting out the fire.

Connection with the module: this lesson is a pure operational skill, and it's the one that makes all the others executable. Lesson 4 gave you a list of improvements to apply to each workflow; this one teaches you to apply them without causing the very damage you're trying to prevent. It rests on the classification from lesson 3 —a change in a critical×irreversible is handled with more care than one in the calm corner— and it prepares lesson 6, because one of the reasons live changes break is not knowing which of the eighteen workflows you're touching. A boundary note right away: here you'll see the operational half of changing a workflow —within one instance. The lifecycle half —having a development environment separate from production and promoting changes from one to the other with Git— is the Git and Environments guide, and I'll refer you to it at the exact point where it begins.

Remodeling the store without lowering the shutter

Let's start with the image that orders the lesson.

There are two ways to remodel a store. The first: you lower the shutter, put up a "closed for remodeling" sign, and work calmly for three days. Nobody comes in, you don't break anyone's experience, and when you open everything is new. The second: the store can't close —it's full of customers right now, and closing costs more than the remodeling— so you remodel with the people inside. You move a shelf at night, when there are fewer people. You test the new paint in the back room before applying it in view. You change one small thing, watch that nobody trips, and only then do you change the next.

A production workflow is the second store. You can't lower the shutter. While you edit order-sync, orders keep coming in. While you adjust shipment-notify, the carrier keeps sending events. The system doesn't stop so you can work comfortably, and that's exactly the problem this lesson solves: how you remodel with the customers inside.

From there comes the rule that governs everything else:

A change in production isn't judged only by whether the result is correct, but by what happens during the transition. The new shelf may end up perfect, but if in moving it you knock over a customer, the change was bad. In a workflow, "the result" is the new version; "the transition" is what happens to the executions that were in progress when you published.

n8n 2.0 —the version this guide is written against, published on December 5, 2025— changed precisely the model of how changes are published, and it changed it to make that transition safer. Let's go with that model, because it's the central tool of the lesson.

Saving isn't publishing

Here's the most important concept of the lesson, and it's a distinction n8n 2.0 made explicit: saving and publishing are two distinct actions, and confusing them is the number-one cause of scares when changing live.

Save. When you edit a workflow in n8n 2.0, your changes save on their own, automatically, every second or two, without you pressing anything. But —and this is the new and important part— saving doesn't affect production. The changes you save stay in a draft state. They exist, they're safe, but they don't run. The version that actually executes when an order arrives is still the previous one.

Publish. It's the explicit act of saying "this version is the good one, let it run in production." When you publish, the version you were editing becomes the live version, and from that moment new executions use it. There's a Publish button in the top corner of the editor, and until you press it, your work is a draft that nobody in the real world is using.

Stop on what this means, because it's freeing: you can edit a production workflow as much as you want without fear, because editing is no longer turning on. You can rewrite half of order-sync, save (automatic), close the tab, come back tomorrow, keep editing —and all that time order-sync keeps processing orders with the old version, the one that works. The change only takes effect the instant you press Publish. The store's remodeling happens in the back room; the shutter only goes up when you decide.

The analogy. It's the difference between writing a document and sending it. Writing an email, saving it as a draft, rewriting it, leaving it half-done, coming back the next day —none of that reaches anyone. The recipient doesn't see a single word until you press "send." Saving is writing the draft; publishing is pressing "send." And just as nobody sends an important email without rereading it, nobody publishes a critical workflow without reviewing it.

A note of honesty about versions, so you don't get confused if you open a different instance: this Save/Publish model is n8n 2.0's. In the 1.x versions, what there was was an activation toggle (Active): a workflow was active or inactive, and editing it while it was active did change what ran, with no intermediate draft step. If you operate a 1.x instance, the "editing is turning on" concept applies and you have to be much more careful. If you operate 2.0, you have the draft safety net. Verify which one you have by looking at whether there's a Publish button (2.0) or an Active toggle (1.x) in the editor.

Worked example: preparing a change without exposing it

Let's do it with shipment-notify. Suppose you want to add a check to it so it doesn't send the same notice twice —the care its cell, important × correctable, called for in lesson 3. It's a change in a workflow that does 2,500 executions a day. Here's how you prepare it without exposing it:

Step 1 — Edit calmly. You open shipment-notify and add the check nodes. Each change saves itself in a couple of seconds. What to expect: somewhere in the editor you'll see a signal that the changes are saved as a draft and that the published version is still another one. While you edit, the 2,500 notices of the day keep going out with the old version. You didn't break anything yet, and you're not going to break it until you publish.

Step 2 — Test it without touching production. Here's the valuable part. You can run the workflow manually from the editor —the canvas's run button— to see how your draft behaves with test data, and that manual execution doesn't count as production: the carrier didn't trigger it, you triggered it, and it doesn't affect the version running live. For the test to be realistic without actually calling the external system, you use pinned data: you attach a sample carrier event to the input node and the workflow runs with that data as if it had really arrived. What to expect: you see the result of your new version, field by field, in the panel, without any customer receiving anything. Pinned data and single-node testing are the subject of all of module 3; here it's enough to know they exist and that they're your back room.

Step 3 — Review the difference before publishing. When you press Publish, n8n lets you review what changed between the live version and the one you're about to publish before confirming. Read it. It's the equivalent of rereading the email before sending it, and it catches the dumb mistake —a node you disconnected by accident, a change you didn't remember making.

Step 4 — Publish when you can watch. You press Publish. The new version takes effect. And you stay watching the next executions for a while, which is the step almost everyone skips and that we talk about below.

Notice what the draft model did: it gave you a back room. You edited, tested, and reviewed without any of that touching the 2,500 daily notices, and only at the end, with an explicit and reviewed act, did you raise the shutter. That's changing live with a net.

What happens to the in-flight executions

Now the uncomfortable question, the transition one: at the exact instant you press Publish, what happens to the executions that were already running with the old version?

And here I have to be honest with you, because it's the kind of detail where making things up would be worse than admitting a limit: n8n's official documentation confirms that new production executions always use the current published version, but it doesn't leave explicitly written what happens to an execution that was already halfway when you published. I'm not going to assert it as if I knew it with documentary certainty. What I'm going to do is teach you to reason about it and to operate the conservative way, which is what an experienced operator does when the documentation doesn't cover a case.

The reasoning. An execution that already started loaded the workflow definition when it began. What's expected —and what it's best to assume while you don't verify it in your own instance— is that that execution finishes with the version it started with, and that only executions that start after publishing use the new version. But "what's expected" isn't "what's confirmed," and there's a case that complicates it: if your change affects how something that was paused resumes —a workflow with a wait, with a second-step webhook, with a branch that continues later— the interaction between the old execution and the new definition can be subtle.

The conservative practice, which is the one you should adopt until you verify the behavior in your instance:

• Don't publish in the middle of a burst. order-sync has its peak at 21:00. Publishing a change at 21:00 is maximizing the number of in-flight executions right when you publish. Publish in a valley —not overnight, for what we'll see about "Friday at six," but at a low-volume hour with people awake.
• Let the queue drain. If you can, look at the executions panel and publish when there are —or almost no— active executions of that workflow. A transition over zero in-flight executions has no possible ambiguity.
• Verify the behavior yourself before trusting it. In a practice instance, with a test workflow that takes a while on purpose —a node with a thirty-second wait— start an execution, publish a different version while it runs, and look in the panel at which version it finished with. That small experiment gives you the real answer for your version of n8n, which is worth more than any assertion from a guide. Note it in your operational documentation.

What to expect. If you publish over a valley or over zero active executions, the transition is clean and you don't have to worry about any of this. The rule becomes simple: the moment to publish is chosen, not improvised, and it's chosen so there's as little in flight as possible. Most of the "I published and things broke" scares don't come from the new version, they come from having published at the worst moment.

The small, reversible change versus the redesign

Not all changes are equal, and the matrix from lesson 3 has a cousin here: a way to classify the change, not the workflow.

The small, reversible change. Adjusting a value, adding a field, correcting a condition, bumping the retry count from 2 to 3. It touches little, it's understood at a glance, and —most important— if it goes wrong, rolling back is trivial: you republish the previous version and you're as you were. These changes can be made almost any day, because the cost of getting it wrong is low.

The redesign. Rewriting the logic, changing how the workflow talks to an external system, restructuring the whole flow. It touches a lot, it's hard to review at a glance, and rolling back may not be trivial if the redesign already wrote different things to external systems during the time it was live. These changes are treated as what they are: a major operation, done with time, with tests, at the best possible moment, and with someone watching.

The practical rule, and it's one of the most useful of the craft: prefer many small, reversible changes to one big redesign. Not because redesigns are bad, but because when something breaks after a small change, you know what broke it —it was the only thing you touched— and you undo it in seconds. When something breaks after a redesign that changed twenty things, you don't know which of the twenty it was, and "rolling back" returns you to the starting point losing all the work. A big redesign can almost always be split into a sequence of small changes, and it's almost always worth doing so.

The analogy. It's the difference between crossing a river hopping from stone to stone and crossing it in a single long leap. With the stones, if one is loose, you notice it when you step on it and you step back. With the long leap, if you miscalculated, there's no going back mid-air. The river is the same; what changes is how many return points you left yourself along the way.

Rolling back: the version history

Everything above rests on a safety net, and it's worth knowing well because it's what makes "rolling back" a real operation and not a hope: the workflow's version history.

What it is. n8n saves the previous versions of your workflows. Each time a change is saved, when you restore an old version, or when you bring one in from a Git repository, a new version is created in the history. Watch out for a documented detail: changes to the workflow's settings don't create a new version; the history versions the canvas, not the settings-tab configuration.

What it lets you do. You open the history from an icon in the editor's header, and on any previous version you have a menu of options that, according to the official documentation, includes:

• Restore version — replaces your current workflow with that previous version. It's the literal "roll back."
• Clone to new workflow — copies that version to a separate workflow, without touching the current one. Useful for comparing or rescuing a piece.
• Open version in new tab — see it without restoring it.
• Download — download that version's JSON.
• Name version — give a version a name to find it later and to protect it from automatic cleanup.

That last point is more important than it seems. Before publishing a big change, give a name to the version that works —something like "before-the-shipping-redesign." That way, if the redesign goes wrong, you don't have to guess which of the automatic versions was the good one: you look for it by its name and restore it. It's the return point marked before jumping.

A note of honesty about the plans. How much history you keep depends on your plan, and this is worth verifying in your instance instead of assuming it, because it changes. According to the documentation current at the time of writing this guide: all users have at least the last 24 hours of versions; the Cloud Pro plan keeps the last 5 days; and the Enterprise plans (Cloud or self-hosted) keep the full history. If you operate on a modest plan and your safety net is 24 hours, that changes how you work: a Monday change can no longer be reverted from the history on Wednesday. That's why, for big changes to critical workflows, don't depend only on the history: download the good version's JSON before touching anything, or —better— use the Git flow the Git and Environments guide teaches, which gives you a permanent history that doesn't depend on the plan. Verify your real retention before trusting it; don't assume you have the full history.

A nuance about rolling back when the effect already went out. Restoring a previous version fixes the workflow, but it doesn't undo what the bad version already did in the world while it was live. If your bad change was published for twenty minutes and in those twenty minutes it sent fifty wrong emails, restoring the good version stops the future emails but doesn't recover the fifty already sent. That —undoing effects that already happened— is compensation, and it's the contracts and idempotency guide. The history gives you back the correct logic; the consequences of the incorrect logic are cleaned up separately. That's why the best "roll back" is the one you don't need, and the best change is the one you tested first in the back room.

Friday at six is not the time to publish

I'll close with a rule that seems cultural but is purely operational, and that sums up the lesson.

Don't publish a change when you won't be able to watch what happens afterward. Friday at six in the afternoon is the canonical example —you publish, you leave, and if something breaks it stays broken the whole weekend with nobody watching— but the rule is more general: the moment to publish is chosen by two criteria, how much is in flight and who can watch afterward.

• How much is in flight: publish in a volume valley, not a peak, for what we saw about executions in transition.
• Who can watch afterward: publish when you —or someone— can stay observing the next executions long enough to notice if something went wrong. A change in a critical is watched at least until you see several successful executions with the new version.

The two criteria sometimes fight —order-sync's volume valley is the early morning, and in the early morning there's nobody awake to watch— and there the second one wins: better to publish at a medium-volume hour with people watching than at a zero-volume hour with nobody watching. A problem detected in minute one gets fixed in minute two; a problem that happens at 03:00 and is discovered at 09:00 had six hours to do damage.

The analogy. No surgeon schedules a big operation for the last case on Friday, when the team is tired and the hospital is emptying out. Not because the technique changes, but because if a complication arises they want the operating room full of awake people, not empty. Publishing a change is opening a patient: do it when the team can respond if something gets complicated.

This connects directly to module 8. One of the things a good operations kit defines in advance is when you can publish and when you can't —what the industry sometimes calls a "change window" or a "freeze" on sensitive dates, like the year-end sales peak. For now keep the simple version: publish when you can watch, and never right before you leave.

Common mistakes

Believing that editing is turning on (conceptual, and dangerous in 1.x). What happens: someone opens a production workflow to "just look at one thing," touches a node by accident, and in a 1.x instance —where there's no draft— that touch already changed what runs. Or, in 2.0, someone doesn't understand the model and believes their edits are already live, and gets nervous editing something that's actually still a draft. Why it happens: the intuition of "what I see on screen is what runs" is strong and was true in 1.x. How to catch it: if you can't say, right now, whether the changes you're seeing in the editor are live or a draft, this is it. How to fix it: learn to read the signal of your version. In 2.0, editing is a draft and only Publish turns it on; there's a visible Publish button. In 1.x, editing an active workflow does change production; be extra careful or deactivate it before touching. Knowing which model you're in is the prerequisite for everything else.

Publishing at the peak (practical). What happens: a change is finished with the urge to see it work, and it's published immediately, without looking at whether it's the worst moment. If that moment coincides with the volume peak, the number of executions in transition is maximized and, if something goes wrong, the damage is multiplied by the volume. Why it happens: the satisfaction of finishing a change pushes you to turn it on now. How to catch it: if you publish without having looked at the executions panel to see how much of that workflow is running, this is it. How to fix it: separate "I finished the change" from "I publish the change." Finish it when you finish it; publish it at the chosen moment —volume valley, people watching. n8n 2.0's draft exists precisely so that separation is comfortable: you can have the change ready on Thursday and publish it Tuesday morning without losing anything.

Depending on the history you don't have (practical, and plan-related). What happens: someone makes a big change trusting that "if it goes wrong, I'll restore the previous version," without having verified how much history their plan keeps. They discover, the day they need to revert, that their plan only kept 24 hours and the good version was already cleaned up. Why it happens: it's assumed the history is infinite, because on the high plans it almost is. How to catch it: if you don't know from memory how many days of history your instance keeps, this is it. How to fix it: verify it in your plan, and for big changes to criticals don't depend only on the history: give the good version a name, download its JSON before touching, or —the robust option— bring the workflows into Git with the Git and Environments guide. The safety net you didn't verify isn't a safety net, it's an assumption.

Exercises

Exercise 1 — Save versus publish. Explain, in one paragraph that would help a new coworker, the difference between saving and publishing in n8n 2.0, and why that difference makes changing a production workflow safer than in the 1.x versions. Use the words "draft," "live," and "back room."

See solution

A possible answer:

"In n8n 2.0, saving and publishing are two distinct things. Saving happens on its own, automatically, every couple of seconds while you edit, but what you save stays as a draft: it exists and it's safe, but it doesn't run. The version that's actually live —the one that executes when an order arrives— is still the previous one until you press the Publish button. That gives you a back room: you can rewrite half a critical workflow, test it, leave it half-done, come back tomorrow, and all that time production keeps working with the old version that does serve. In the 1.x versions there was no back room: editing an active workflow changed what ran at the moment, with no intermediate step, so 'looking at one thing' in a running workflow was already dangerous. The practical difference is enormous: in 2.0 editing stopped being turning on, and turning on is now a separate, explicit, and reviewable act."

Why it works: the answer captures the three ideas that matter —the draft as a safe state, the separation between editing and turning on, and the contrast with 1.x where that separation didn't exist— without getting tangled in interface details that change between versions.

Exercise 2 — Choose the moment. You have a change ready in order-sync (critical × irreversible, peak at 21:00, valley overnight, warehouse packs from 07:00 to 16:00). It's Thursday. Propose when you would publish it and justify with the two criteria of the lesson (how much is in flight, who can watch). Then say which moment you'd rule out and why.

See solution

A defensible answer: not Friday morning, better Monday or Tuesday early in the morning, say at 08:00–09:00.

Reasoning through the two criteria:

• How much is in flight: at 08:00 order-sync's volume is low —the peak is at 21:00— so there are few executions in transition. It's not the absolute valley (the early morning), but it's low enough.
• Who can watch: at 08:00 on a Tuesday the team is coming in, awake and available. If the change breaks something, it's detected in minutes and there are people to act. And it coincides with the warehouse's start (07:00), so if something went wrong with order creation, it's noticed soon in the real operation.

Why the second criterion wins over the first: order-sync's absolute valley is the early morning, but at 03:00 there's nobody watching. Publishing a critical at that hour maximizes "how much is in flight" in your favor but destroys "who can watch." A problem at 03:00 has until 09:00 to do damage. Better low-volume-with-people than zero-volume-with-nobody.

What to rule out: Friday afternoon, by the canonical rule —you publish and leave, and a failure drags on the whole weekend with nobody watching; and 21:00 of any day, because it's the peak and it maximizes the executions in transition precisely in the workflow where losing one hurts most.

Why it works: the exercise forces you to resolve the tension between the two criteria, which is where the real judgment lives. The correct answer isn't an exact hour, it's having weighed "in flight" against "who watches" and having chosen consciously, giving priority to being able to respond if something gets complicated.

Exercise 3 — Verify what the guide doesn't confirm. The lesson admits that the documentation doesn't make clear what happens to an execution that was already running when you publish. Design the concrete experiment you would run in a practice instance to find out yourself, step by step, and say what you would observe to conclude one thing or the other.

See solution

A possible experiment, in a practice instance (never in production):

1. Create a test workflow that takes a while on purpose. A manual trigger or a webhook, followed by a Wait node of, say, 60 seconds, and then a node that leaves a clear trace of which version ran —for example, a Set node that writes a field version: "A", and that at the end saves that data somewhere you can see it (a row in your practice Postgres, or simply the execution panel).
2. Publish version A and start an execution. Trigger it and confirm that it entered the 60-second wait: now you have an "in-flight" execution.
3. While that execution waits, edit and publish version B. Change the field to version: "B" and press Publish. You've now published a new version with an old execution halfway through.
4. Wait for the old execution to finish and look at its result. Here's the answer: if the execution that started with A finishes writing version: "A", then in-flight executions keep the version they started with —the conservative hypothesis. If it finishes writing version: "B", then on resuming it took the new version, and that completely changes how you have to treat workflows with waits.
5. Repeat by starting a new execution after publishing B, to confirm what the documentation does say: that new ones use the current published version (they should write version: "B").
6. Note the result with your n8n version, because this behavior can change between versions and what counts is what your instance does.

Why it works: the experiment isolates exactly the question —which version an execution that crosses the publication moment uses— with an observable trace (A vs B) and a wait that guarantees the execution is in flight when you publish. And it models the most valuable reflex of the craft: when the documentation doesn't cover your case, you don't guess or make things up, you design the smallest test that gives you the real answer.

Summary and next step

In this lesson you learned to remodel the store without lowering the shutter. With that image the rule landed: a change in production isn't judged only by whether the result is correct, but by what happens during the transition. The central concept was n8n 2.0's distinction between saving —automatic, leaves the change in a draft, doesn't touch production— and publishing —the explicit act that puts the new version live— which gives you a back room to edit, test with pinned data, and review the difference without exposing anything, and which only turns on when you press Publish. About the in-flight executions I was honest: the documentation doesn't confirm which version an execution that crosses the publication moment uses, so you adopt the conservative practice —publish in a valley, drain the queue, and verify it yourself in your instance— and you don't assume. You saw the difference between the small, reversible change —always preferable, because rolling back is trivial— and the redesign —which is split into small changes— with the image of the river stones versus the long leap. You learned about the version history —restore, clone, name— its per-plan limit that has to be verified, and the nuance that restoring fixes the logic but doesn't undo the effects already out. And you take with you the Friday at six rule: publish when you can watch, choosing the moment by how much is in flight and who can respond if something gets complicated.

Before moving on you should be able to: explain saving versus publishing and why the draft makes changing live safer; name the conservative practice for in-flight executions; and justify the choice of a publication moment with the two criteria.

Lesson 6 solves a problem that peeked out here without my naming it: to change a workflow safely, you first have to know which of the eighteen you're touching and what it touches. You'll see how a catalog is made operable with a naming convention that says what each workflow does and which system it touches, tags by criticality and by system —verifying what n8n actually offers and in which plans— and the inventory as a living document. And you'll understand why "Workflow copy 3 (final)" isn't a careless name but an incident waiting to happen.

Resources

• Save and publish workflows — n8n Docs — n8n 2.0's draft-and-publish model, center of this lesson: autosave, the Publish button, how to unpublish, and the integration with the version history. The main reference for verifying everything here in your own version.
• View change history — n8n Docs — the version history: restore, clone, open, download, and name versions, and —what has to be verified in your plan— how much history is kept (24 hours for everyone, 5 days on Cloud Pro, full on Enterprise).
• Understanding workflow publishing in n8n 2.0 — n8n Help Center — the explanation of the model change relative to the 1.x versions, useful if you operate a mixed instance or come from 1.x.
• Understand executions — n8n Docs — what a production execution is versus a manual one, the basis for understanding why testing from the editor doesn't touch the live version.
• Release notes 2.x — n8n Docs — the history of version 2, where changes like the visual difference between versions (visual diff) are documented. Useful for confirming exactly what your version brings.