{
  "id": 17408421,
  "title": "The Deploy That Broke Running Jobs: Changing an n8n Workflow While Executions Are In Flight",
  "url": "https://urgent.news/2026/10/31/the-deploy-that-broke-running-jobs-changing-an-n8n-workflow-while",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-10-31T13:36:55.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/haopengai/the-deploy-that-broke-running-jobs-changing-an-n8n-workflow-while-executions-are-in-flight-335i"
  },
  "original_language": "en",
  "account": "When running LLM workflows in n8n in production, changing a workflow while executions are in flight can be challenging. The key rule is to snapshot the current version before making any changes. This involves exporting the current version with a date and a one-line note about its function. Rollback becomes a simple reactivation of the old export, rather than a reconstruction effort.\n\nBefore deploying, it's crucial to drain the system. This means stopping new work from entering the workflow to avoid mixed old and new runs. Pause the trigger or deactivate the workflow to allow all in-flight executions to finish. Check the execution list for any jobs stuck in places like the dead-letter queue or review queue. Only after confirming zero in-flight executions should you then change the workflow.\n\nAfter deploying, run a canary job through the new version first. This job should be a full end-to-end job with harmless payload. The canary helps catch issues like renamed fields or steps that only matter with a full payload. If the canary's output matches the expected result, only then re-enable the trigger. If the canary fails, rollback using the snapshot from earlier. Remember, rollback only restores the workflow definition and does not undo the side effects produced by the new version.\n\nA rollback plan should include reactivating the old version and listing the jobs that ran on the new version so their outputs can be checked manually. This ensures that side effects from the new version are not double-applied when the workflow is rolled back. This process, while requiring extra steps, has saved the author from the pitfalls of mixed-version runs, making workflow deploys safer and more predictable.",
  "summary": "This is part of my build-in-public series on running LLM workflows in n8n in production. Everything here is from real templates I sell and support — the mistakes are mine, the fixes are tested. The change was small. The queue was not empty. I once edited a live workflow in the middle of the day. The change was small: one extra field on an outgoing message, one renamed step. I saved, reactivated,…",
  "key_points": [
    "Snapshot current n8n workflow before changes",
    "Drain system by pausing trigger to stop new runs",
    "Canary test new workflow version before full enable"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}