n8n Definition Diff vs Behavior — When JSON Looks Fine
n8n history and Git diffs compare workflow definitions — the JSON. Behavior testing replays an edit against recorded real runs and compares each node’s output, so a change that looks fine in a definition diff can still be blocked when the behavior is wrong.
What does an n8n definition or history diff show?
It shows what changed in the workflow definition (the JSON) — nodes added, removed, or reconfigured. It does not prove that outputs still match what those nodes produced on real client runs.
Version history and Git compare are the right tools for “what changed in the file.” They are not a proof that client-facing behavior stayed the same.
When does a clean definition diff still break clients?
When an edit changes behavior in a way the JSON does not make obvious: an expression that now resolves to nothing, a field renamed while a later node still reads the old name, a condition that sends items down a different branch. The JSON can look fine while outputs are wrong.
Two more causes leave a definition diff clean and are beyond a replay as well: an edited sub-workflow, whose call a replay of the parent answers from the recording, and an outside API whose response changed, which a replay also answers from the recording.
That is the silent-success class of risk: the run finishes green, the definition review looks calm, and the client sees wrong data downstream.
That class of risk in depth: n8n succeeded but wrong output.
How is behavior testing different from n8n history?
History/version compare tells you what changed in the file. Behavior testing reruns the edited workflow on recorded inputs and diffs what each node actually produced — success status alone is not enough.
Preflight is built for that second check: record real executions, replay the edit in a sandbox, and read per-node output diffs before you deploy.
Definition diff vs Preflight — side-by-side
| Definition / history diff | Preflight behavior gate | |
|---|---|---|
| Compares | Workflow JSON / canvas versions | Node outputs on recorded real runs |
| Answers | What changed in the file? | Did behavior stay safe? |
| Catches | Structural edits you can see in the definition | Wrong-but-green runs definition diffs miss |
| Best for | Review and rollback of the workflow file | Client delivery gate before deploy |
| Available on | Version compare on Pro, Business and Enterprise; Git diffs on self-hosted Business and Enterprise, and Cloud Enterprise, once environments are switched on | Self-hosted n8n, Community included, through its public API; in beta, on the n8n versions its sandbox supports |
n8n plan availability from n8n’s docs: version compare (the n8n 2.13 entry, “Visual diff in version history”), Git workflow diffs. Checked 30 October 2026.
Preflight is an independent tool for n8n, not affiliated with n8n GmbH.
When should agencies use both?
Use definition/history diffs for review and rollback of the workflow file. Add a behavior gate before client delivery when silent wrong-output risk matters — especially for agencies running many client instances.
History for “what changed.” Preflight for “did behavior stay safe.”
Sub-workflows need one more step, because a replay of the parent answers each sub-workflow call from the recording: how to test a sub-workflow change before publishing it.