n8n workflow history: restore a broken workflow without panicking

The scenario is always the same. A workflow has been running in production for months, someone opens the editor to "just tweak one field", and within the hour the alerts start firing. n8n does keep a version history, with a preview and a restore button — but retention depends on your plan, it is shorter than you would expect, and a restore does not fix everything. This guide covers the emergency first, then prevention.

What n8n records, and when

According to the documentation, n8n creates a new version in three situations:

• when you save the workflow — the editor now autosaving as you edit, as covered in the n8n 2.0 save & publish guide;
• when you restore an older version: n8n saves the current state before restoring, which always leaves you a way out;
• when you pull from a Git repository through Source control — those versions are written to the instance database, not to Git.

An often-missed point: changes to workflow settings do not create a version. Changing the timezone or the error workflow leaves no trace at all.

Do not confuse this with executions, which are runs of the current version, replayed while debugging a workflow. A history version, by contrast, stores the full node list, the connections, the author and the timestamp.

Where to find it and what you can do

Select the Workflow history icon in the workflow header. n8n shows a panel listing the saved versions, and the canvas switches to a preview: you see the graph as it was, without changing anything. On each version, the Options menu offers five actions:

• Restore version: replaces the current workflow with the selected version;
• Clone to new workflow: creates a new workflow from that version;
• Open version in new tab: opens a second tab, so you can compare side by side;
• Download: downloads the version as JSON;
• Name version: names and describes the version, which then becomes protected from automatic pruning (available on Cloud Pro, Enterprise and self-hosted Enterprise).

The production reflex is not "Restore" but "Clone to new workflow": you get an inactive copy, you compare it against the broken workflow, and you only switch once you are sure.

Retention depends on your plan

No illusions here. The n8n documentation lists three tiers: 24 hours of versions for all users, 5 days on n8n Cloud Pro, and full history on Enterprise plans, both Cloud and self-hosted.

A self-hosted Community instance therefore lives with a 24-hour window: enough to undo yesterday's mistake, nowhere near enough to find "the version that worked before the holidays" — a limit to file alongside the other trade-offs in the free n8n limits guide.

The self-hosted environment variables

Only one variable is documented today for workflow history:

# How long to keep workflow history versions, in hours.
# -1 (the default) = keep all versions indefinitely.
N8N_WORKFLOW_HISTORY_PRUNE_TIME=-1

The trap is how it interacts with the licence: in the n8n source, the effective prune time is the minimum of the licence limit and the configured value, with -1 meaning "infinite" on both sides. If the licence caps you at 24 hours, leaving -1 changes nothing. Conversely, on an Enterprise instance, 720 (30 days) deliberately caps database growth.

One detail worth flagging, because it still lingers in plenty of docker-compose.yml files: N8N_WORKFLOW_HISTORY_ENABLED, which defaulted to true and switched version recording off, existed in the 1.x line but disappeared from the code in 2.0. If you find it, it no longer has any effect — exactly the kind of leftover you hunt down when reviewing your environment variable inventory.

The database cost

Every version is a full record: nodes and connections serialised as JSON, plus metadata. A thirty-node workflow with long AI prompts easily weighs several hundred kilobytes per version. Multiply by a day of intensive editing and by the number of workflows: history becomes a table to watch just like the executions table, with the same reasoning as cleaning up n8n executions. And it lives inside that database: it is no substitute for a proper PostgreSQL backup. Lose the database and you lose the workflows and their history.

What history does not restore

This is what explains most restores that "still do not work": a version contains the workflow structure and nothing else. The following do not come back:

• credentials, referenced only by ID and name: if one was deleted or re-scoped, the restored version points at nothing;
• execution data: restoring replays nothing;
• instance variables, which are not versioned alongside the workflow;
• sub-workflows called by an Execute Sub-workflow node, which have their own separate history. Restoring the parent without the child produces a combination that never existed;
• workflow settings, which as noted do not even create a version.

This split between an artefact and its environment is a classic of the systems reliability literature. In "An Empirical Study on Configuration Errors in Commercial and Open Source Systems", published in 2011 at SOSP, Zuoning Yin and co-authors analyse 546 real-world misconfigurations, 309 of them from a commercial storage system deployed at thousands of customers, and show that 70 to 85% of them stem from mistakes in the parameters themselves (see on Google Scholar). Applied to n8n: a correct workflow pointing at an inconsistent credential breaks just as reliably as a buggy one.

The emergency runbook

1. Deactivate the workflow (or unpublish it): while it runs, every execution deepens the side effects.
2. Open the history and find the timestamp just before the offending change; the displayed author tells you who touched what.
3. Preview the last healthy version on the canvas, without restoring anything.
4. Clone it through Clone to new workflow: you now have the healthy copy and the broken workflow side by side.
5. Diff the two JSON files outside n8n (see below): this is the step that stops you reintroducing a regression along with the fix.
6. Switch over, then re-check the credentials before reactivating.

Comparing two versions with diff and jq

The canvas is great at spotting a missing node and terrible at spotting a changed parameter in one node out of thirty. Grab the healthy version's JSON through Download, and the current one through the n8n REST API or a manual workflow export:

# Current version, through the public API
curl -s -H "X-N8N-API-KEY: $N8N_API_KEY" \
  "https://n8n.example.com/api/v1/workflows/AbCdEf123456" > current.raw.json

# Normalise: keep only what matters, sorted by node name.
# Canvas positions and internal IDs are pure noise.
NORM='{nodes: [.nodes[] | {name, type, typeVersion, parameters, credentials}] | sort_by(.name), connections}'

jq -S "$NORM" current.raw.json > current.json
jq -S "$NORM" healthy.raw.json > healthy.json

diff -u healthy.json current.json

Without the jq step, dragging a single node with the mouse produces dozens of diff lines and drowns the real change. With it, the diff often fits in five lines.

The traps

• Relying on a history that is not there. On a Community instance the window is 24 hours. By the day you need it, it is too late to change plan;
• Restoring a version that references a deleted credential. The calls fail on authentication and nobody understands why "the good version" does not work. Reopen the node and reselect the credential;
• Assuming a restore undoes side effects. The 4,000 emails already sent are not coming back. That is the real argument for designing idempotent workflows rather than reassuring yourself with a rollback button;
• Deleting or archiving the workflow. History is tied to it by a cascading delete: the workflow goes, its versions go with it;
• Editing as a team without saying so. n8n only lets one person edit at a time and puts everyone else in read-only mode, but nothing stops two colleagues taking turns within the hour and producing an unreadable history;
• Mistaking history for a backup. Automatically pruned, stored in the database, stripped of credentials: it is not a recovery plan.

Real prevention, in three levels

History is a safety net, not a strategy. Three practices reduce how often you need it:

1. Version workflows in Git, exporting their JSON through the n8n API — the subject of the guide on backing up and versioning n8n workflows in Git. Unlimited history, git blame, code review;
2. Separate development and production, so a change never lands directly on the running workflow — the approach described in the dev/prod environments with n8n guide;
3. Validate before deploying, with automated checks on the exported JSON, as in the validating n8n workflows in CI with GitHub Actions pipeline.

This is not over-engineering. In "When do changes induce fixes?", published in 2005 at Mining Software Repositories (ACM SIGSOFT Software Engineering Notes), Jacek Śliwerski, Thomas Zimmermann and Andreas Zeller analysed the Mozilla and Eclipse archives to identify the changes that later trigger fixes, and showed that these "fix-inducing" changes follow clear regularities, notably in their size and in the day of the week they are applied (see on Google Scholar). Their method, which became the SZZ algorithm, rests entirely on the existence of a usable history: with no record of the changes, there is no way back to the cause. A workflow edited straight in production on a Friday evening ticks every box.

Key takeaways

History opens from the Workflow history icon and offers Restore version, Clone to new workflow, Open version in new tab, Download and Name version. On self-hosted, it is tuned with N8N_WORKFLOW_HISTORY_PRUNE_TIME (in hours, -1 to keep everything, subject to the licence limit). Three numbers to remember: 24 hours for everyone, 5 days on Cloud Pro, full history on Enterprise. And one conceptual limit: restoring a workflow restores neither its credentials, nor its variables, nor its sub-workflows, nor the side effects already produced. In an emergency, clone before you restore. The rest of the time, put your workflows in Git.

Going further

Version discipline counts double on workflows touching sensitive data or traceability obligations. The Compliance & Audit Pack (€149) is built on exactly that logic: workflows where every run leaves evidence, and where changes have to be justifiable after the fact. If you are industrialising several automation chains in parallel, the Complete FlowKit Bundle (€269) provides a base of already structured workflows, ready to be exported and versioned in your repository from day one.