The anatomy of a published n8n template

The median public template has 12 nodes. The mean is 15.1, pulled up by a long right tail — the largest template measured has 213. Half of all templates sit between 8 and 18 nodes; one in ten is above 27.

That tail is why this site exists, though the connection is an opinion rather than something measured here: nothing in this dataset records legibility, and we did not test it. What the distribution does say is that a template at the 90th percentile carries 2.3× the nodes of the median one, and the top percentile 5.3× — so whatever size defeats a screenshot for you, a real share of the library sits past it.

The average workflow has 15.1 connections — about 1 per node. That close to one means most workflows are predominantly linear chains with a few branch points, rather than dense graphs.

52.5% contain an if or switch, and 19.6% bring paths back together with a merge. Splitting is common; rejoining is not.

Connection figures are measured on 10,951 of the 10,957 workflows. 6 store their connection map in an older or hand-edited format this analysis will not guess at, so they are left out of these two numbers only — their node counts are still included everywhere else.

The schedule trigger leads at 30.5%, with manual behind it at 22.9% — no single entry point accounts for even half the library. Percentages sum to more than 100 because a workflow can have several triggers.

0.7% of templates have no trigger node at all — fragments published as building blocks rather than runnable workflows.

Start with the top of the ranking below, because it is not what n8n's positioning would lead you to expect: the single most-used node in the template library is the plain Code node, in 54.1% of templates. More published templates contain hand-written JavaScript than contain any integration.

Two more figures are worth sitting with. The first is AI: 55.5% of public templates contain a LangChain node, which makes AI orchestration an ordinary part of the library rather than a category within it. That figure gets quoted more than anything else here, so the exact rule and every node type it matched are listed below — and note what it excludes: a hand-rolled HTTP call to an LLM API is not counted, and neither is the base-package OpenAI node.

The second is error handling. Only 14% of templates configure a non-default onError anywhere — nearly every published workflow assumes every step succeeds, which is worth knowing before you run one in production.

Sticky notes go the other way: 91.1% of templates carry at least one, averaging 6.1 where present. Authors publishing a workflow for other people to read annotate it far more readily than they guard it — which is exactly why a rendered diagram keeps them.

1,064 distinct node types appear across the library. These are the ones that show up in the most templates — core building blocks included, because the shape of the list is the point.

That breadth is thinner than it looks. Across 165,076 node instances in 1,064 distinct types, the top ten types alone account for 49.5% of every node placed, and the twenty in this table for 65.2%. The other 1,044 types share the remaining 34.8%.

Read that as a shape rather than a headline: the catalogue is wide, the usage is not. Nearly all of what gets built is assembled from a few dozen node types, and the rest of the library exists in the tail.

The same ranking with the plumbing removed — no if, set, code, agents or output parsers — leaving the services people actually connect to.

Integration pairs that co-occur most often in the same workflow. This is the closest thing to a map of what people are actually automating.

Every classification rule, with the node types it actually matched. If a figure above cannot be reproduced from this section plus the published data, it should not be quoted.

All three files are output of the same script that produced this page. Between the two CSVs every figure above can be recomputed from scratch — the per-template rows carry the size, shape, trigger and feature numbers, the per-node-type rows carry the ranked tables and the concentration. The JSON is the aggregate the page renders from, so treat it as convenience rather than as evidence: checking a number against it only tells you the page read its own file correctly. CC BY 4.0 — use them anywhere, credit the page.

Source. The public n8n.io template library, read through its public API — the id list from the paginated search endpoint, then each template fetched individually, throttled and cached. Every one of the 11,015 listed templates was requested. 58 ids returned no workflow and were skipped. No Pixtex user data was used, and none ever will be — the value of these numbers is that anyone can reproduce them from the same public source.

Limits. Public n8n.io templates only. Templates are built to be shared, so they skew simpler than production workflows and over-represent whatever the library is promoting — currently AI. This describes a published n8n template, not a private production workflow. Beyond that: a census has no sampling error, but it is still a snapshot — the library grows weekly, and these figures are dated accordingly. Sticky notes are excluded from node counts. A template is counted once per feature however many matching nodes it contains. Error handling is only visible where a node sets onError; workflow-level error workflows do not appear in template JSON at all, so the true rate is somewhat higher than the one reported here.

Reuse. Everything here is CC BY 4.0 — quote it, chart it, build on it, with attribution to Pixtex — The anatomy of a published n8n template. The raw data is above. If you want a cut we did not publish, ask and we will run it.