The 97% n8n Statistic Has No Source. We Measured It Instead

If you have read anything about n8n reliability, you have seen the number. Sometimes it is attached to workflows that fail in production. Sometimes to workflows that lack error handling. The number itself is almost always the same: 97%.

We went looking for where it came from. It does not come from anywhere. There is no survey behind it, no dataset, no measurement. So instead of repeating someone else's number, we built a pipeline that measures the real thing, and ran it against 2,403 publicly shared n8n workflows across two independently licensed corpora.

While building that tooling, we ran into something nobody appears to have checked. The most-reused public n8n workflow corpus has a data-integrity defect traceable to one specific commit. It has been there since November 2025 and it is still unfixed.

This piece covers both. The anatomy of a statistic that does not exist, and the numbers that do.

The claim, traced back

The claim travels in two versions, and they are worth separating, because they say different things.

• The production version: "97% of n8n workflows that work in testing fail once they go live."
• The configuration version: "97% of n8n workflows lack proper error handling."

We found the first in a content package from a site called AI Fire: a video, a podcast episode and a blog post shipped by one brand within two weeks in June 2026. The number is labelled "estimated" there, and that single word carries the entire weight of the claim. No link, no methodology, no dataset, no survey. We checked. While we were there we noticed the same piece carries two more unsourced statistics: that 60 to 70% of API failures are transient, and that header authentication eliminates over 90% of webhook security issues. Neither has anything behind it either. Three invented-sounding percentages in one piece about reliability is, at minimum, an irony worth noting.

The configuration version turns up elsewhere, including in a piece dated January 2026 in its own URL and signed by "Jarvis, AI operations lead", whose identity cannot be verified. That is a different claim, about configuration quality rather than post-deployment failure, wearing the same number and backed by just as little.

Elsewhere the same rhetorical shape shows up with 90% attached, and elsewhere still with 80%. Nine publications checked, two different claims, three different numbers, and not one citation connecting any of them to a common origin. There is no citation chain here. There is parallel reuse of the same hook with a round number picked at random. That is what invented statistics look like when they spread through content marketing. Real measurements do not drift between 80 and 97 depending on who is repeating them.

So we stopped repeating it and measured instead.

What we actually did

This is static analysis, not a production audit. We downloaded publicly shared n8n workflow files and read the JSON. We deployed nothing, sent no traffic to anyone's webhook, and executed no workflow's code. Every number below is a count of one specific field or node type across a specific, commit-pinned set of files. Every one of those files is independently downloadable, so you can recount it yourself.

We ran the same detectors against two corpora with no shared authorship and no shared curation:

• Primary corpus: Zie619/n8n-workflows, MIT licensed, pinned at commit 94007c1445d9, 2,061 workflow files.
• Secondary corpus: enescingoz/awesome-n8n-templates, CC BY 4.0, pinned at commit 728fd947, 342 files.

Every detector reads one named field and never searches for a word across a whole file. That distinction matters. An earlier prototype searched for "upsert" anywhere in a workflow's parameters and matched 21 sticky notes where someone had used the word in a comment. The version that shipped reads exactly parameters.operation, on the node type where that field means something, and nothing else. Every detector is unit-tested against hand-built fixtures before it touches real data.

We also split findings into two confidence tiers, and only one of them appears as a headline number here:

• Tier A and B, reported as fact. A boolean or a specific field, read directly, covered by tests. No judgment call involved.
• Tier C, candidate only, not reported. Anything requiring interpretation of intent (does this conditional actually check for a duplicate, or is it unrelated business logic?) needs a second, independent annotator and human adjudication of disagreements. We have not finished that step, so two categories, idempotency patterns and input-validation patterns, are excluded from this piece entirely. We would rather publish fewer numbers we can defend than more numbers we cannot.

What we measured

On the primary corpus, 2,061 files deduplicated to 1,720 unique structural families by node-type composition:

"Any node-level recovery mechanism" is a composite. It is true when a workflow has a retry, continuation past a failure, or an Error Trigger anywhere in it. It deliberately excludes one very common node: stopAndError, which appears in over half the primary corpus's files. That node recovers from nothing. It is a deliberate, intentional abort. Counting it as error handling, which an earlier pass through this exact question did, would have been the same category of mistake as the statistic we are debunking: inflating a number by counting the wrong thing. We measure it, we just do not call it recovery.

The number we would stake the most on

The webhook-authentication result is the one we defend most firmly, because it is the one that held up under cross-validation. Run against the secondary corpus, with a different license, a different curator and no shared history with the primary set, the same measurement comes back at 91.2%, which is 62 of 68 webhook-bearing workflows. Two corpora nobody assembled together, agreeing to within 1.2 points, on a question nobody had actually measured before.

One caveat we do not want to bury. In the primary corpus, the values that mean "authentication is configured" look like template expressions rather than the real field values a live n8n instance writes. That is most likely an artifact of whatever tool curated the corpus. It does not affect the configured-or-not answer, but it does mean this corpus cannot tell you which authentication method someone picked. So we report only the first thing.

Checking our number against the only other public audit

In May 2026 a security firm called AIronClaw published a static-analysis audit of 12,750 n8n templates, combining the top 1,000 most-viewed templates from n8n.io with the full contents of eight community GitHub repositories. Reading their methodology closely, we found both of the corpora we used named explicitly in their repo list.

Their headline figure for webhook authentication is 17.0%, which is 2,171 of 12,750 templates flagged for an unauthenticated webhook. Read next to our 92%, that looks like a contradiction. We do not think it is, and the reason is worth walking through, because it is a methodology point rather than a disagreement about facts.

Their 17.0% is computed against all 12,750 templates, including the roughly 80 to 85% of workflows that have no webhook at all and were never going to be flagged by that check regardless of configuration. Our number is computed against only the workflows that have a webhook in the first place. Those are different denominators answering different questions. A rough check makes the reconciliation plausible: if webhooks appear in their combined corpus at close to the rate we measured in ours, roughly 15 to 20% of workflows, then 15 to 20% of 12,750 lands almost exactly on their reported 2,171 affected workflows. That is consistent with a scenario where nearly every webhook in both audits lacks authentication, and the two published numbers are the same underlying fact expressed against two different bases. We cannot prove that reconciliation without their raw per-workflow denominator, which is not published, but the arithmetic lines up closely enough that we think the more alarming reading is the more likely one.

One more figure from their audit is worth citing, because it independently supports a decision we made in our own methodology. Their scanner flags 85.7% of the combined corpus, 10,927 of 12,750, as having no error handling, with a caveat in their own writeup: n8n requires an explicit, workflow-level opt-in to configure an error workflow, and most templates ship without ever setting it. That is very likely the same field we found and excluded from our results early on, settings.errorWorkflow. It references a workflow ID local to the instance that created it, and that reference is stripped or nulled the moment a workflow is exported as a shareable template. It is not that 85 to 100% of authors chose not to configure error handling. That field cannot survive being turned into a template at all, on either corpus. We built our headline recovery number out of node-level fields precisely because this one does not measure what it looks like it measures. An independent scanner landing on a similarly extreme number from the same likely cause is a second confirmation that this is a real property of how n8n templates are exported, not an artifact of one detector.

The corpus everyone reuses has a bug nobody flagged

Building the deduplication logic, we needed to check whether two workflow files were structural near-duplicates by comparing their connection graphs, not just their node lists. That is when we noticed that the primary corpus's connections field, the part of the file that says which node feeds into which, does not do what it is supposed to.

Across the primary corpus we counted every connection-target reference: 27,544 of them. Of those, exactly 19 resolve to a real node by name, zero resolve by ID, and 27,525, or 99.93%, point to a node ID matching the pattern error-handler-<uuid> that does not exist anywhere in the file. In 1,363 of 2,061 files, at least one connection points into a void.

We did not stop at "this looks broken." The source repository's full commit history is public, so we traced it. The break originates in a single commit, 5ffee225, dated 3 November 2025, authored by the repository's own owner with Claude as co-author, titled as a comprehensive fix for eighteen open issues. Its message claims, among other things, to have "restored connection definitions to enable n8n import." We verified that claim directly against the file history. Before that commit, one sample file's connections pointed to a node named "Error Handler for d8c07efe", and that node existed. At that commit a different node replaced it, but the connection entry pointing at the old, now-nonexistent node was never updated. We diffed the same file between that commit and the commit our analysis is pinned to today: byte-identical. The break was never touched again. We also confirmed our pinned commit is a direct descendant of the fix commit. Of the 57 commits in between, only two touch anything under the workflow files at all, and both are pure additions of new files, with zero modifications to anything already there.

The likely mechanism is readable in the fix script itself, which we read and never executed. It identifies orphaned nodes by matching on node name, while this corpus's connections are keyed by node ID in most files. That mismatch would silently defeat the script's own cleanup logic for exactly the files where it mattered most.

We are not naming this to embarrass anyone. The repository has more than 56,000 stars and has clearly had real, sustained maintenance effort put into it, including a documented, good-faith attempt to fix precisely this problem. The point is narrower and, we think, more useful. This dataset has been reused as source material by at least one other public analysis we found in our research, and it sits inside the combined 12,750-template corpus behind the only other audit we compare against above. As far as we can tell, nobody checked whether the connection graph itself was trustworthy before counting things in it. We ran the identical check against our secondary corpus, different license, different owner, no shared history, and got zero broken references out of more than 4,300. Whatever happened here is specific to this one repository's history, not a general property of how n8n exports templates.

Practically, this means any statistic drawn from this corpus's workflow topology, which node leads to which, whether a conditional sits downstream of an entry point, is not trustworthy on this dataset, full stop. Statistics drawn from individual node fields, such as whether this node has retryOnFail set or whether this webhook has an authentication value, are unaffected. Those fields do not depend on the connections graph resolving correctly, and we independently confirmed that the fields we do report resolve identically whether we group results by individual file or by deduplicated structural family. But stopAndError prevalence and anything connections-shaped, we report only as a property of this specific corpus, never as a fact about n8n workflows in general.

What we are deliberately not claiming

• Idempotency and input-validation rates. Both are Tier C in our pipeline: structurally detected candidates that have not been through second-annotator review and human adjudication. We are not publishing a number we cannot yet defend.
• How people actually run n8n in production. Every figure here describes published templates, the starting point someone clones, not what it looks like after a real team configures, hardens and deploys it. Templates are a lower bound on effort invested, not a census of live systems.
• A single, unified n8n reliability score. We report each dimension on its own denominator, on purpose. A workflow with no webhook cannot have an unauthenticated one, and collapsing that into one number is exactly the category error that produced the 97% figure in the first place.

What this means if you run n8n in your company

Three things to check in your own flows, in order, without reading any code.

• What happens when an external system does not answer. In published templates the answer is usually nothing, because only 5.2% have retries configured. If your flow pulls data from a supplier's API or pushes an invoice into accounting, one momentary outage on the other side should not kill the whole run.
• Who finds out that something broke, and how many hours later. A dedicated Error Trigger node, the mechanism that sends a notification when something fails, is present in under one percent of templates. Automation that goes quiet when it stops working is more dangerous than no automation, because for a week everyone assumes the work is getting done.
• Who can trigger your flow. A webhook is an address anyone who knows it can post to. If it writes to a database, sends email, or does anything that costs money, it belongs behind authentication. In published templates it is not, in more than nine cases out of ten.

If you want to know what doing this properly costs from the start, we wrote that up separately in how much n8n automation costs. The rules we work by, the client's own server, keys on the client's side, and workflow exports in the client's repository, are in the services section.

Reproduce this yourself

The detector package, the corpus-fetching script with pinned commit SHAs, and the full writeup of the connection-graph finding are open source: github.com/adix65/n8n-reliability.

python3 -m n8n_reliability.cli fetch-corpus --dest data/corpus/n8n-workflows
python3 -m n8n_reliability.cli analyze --corpus-dir data/corpus/n8n-workflows --out-dir out

Every number in this piece has a numerator, a denominator, and a plain-language definition of that denominator in the output. If a percentage in this article cannot be traced to those three things, treat it as a bug in the article, not a fact about n8n.

If you run n8n flows and want to know which of them go quiet when they fail, get in touch. We will walk through them on your data, on a free call.

SEVENEDGE builds and runs self-hosted n8n automation for production clients, alongside custom business software. This piece is static analysis of publicly shared workflow files, not a claim about any specific client system.