Named by 9 of 26 clients, usually as a plus rather than the job
247 automations.
86 running now.
Those two numbers were read from the n8n API when this page loaded, not typed in. A note in my own files said 245 and 84 for months, which was true once and quietly stopped being true, and a remembered number is exactly the kind that ends up in a proposal.
The names are not shown. Most of these are built for clients and the names say who, so a count is safe to publish and a list is not. The one described below is the one built for this site.
This one probes every service behind this site and writes the result to a table. The runs below say trigger, which means the schedule fired them rather than somebody pressing a button.
223 checks recorded so far. The results are on the status page, including the ones where my own probe was wrong.
What a count does and does not tell you
It says the estate is real and it says nothing about quality. Plenty of these are three nodes long, some have not run in months, and a few exist because a client asked for something once. Anybody quoting a workflow count as a capability is quoting the easiest number to inflate.
The useful part is the shape of the one above. It runs without anybody watching, writes evidence somewhere durable, and goes red when the thing it watches breaks. An automation nobody would notice failing is a liability.
Two shapes in that workflow were read off other workflows already running on the box rather than guessed from documentation. This n8n wants a cron expression where the docs suggest an interval, and the HTTP node’s header list is plural. Both were rejected with the same unhelpful message.
The endpoint returns counts and never names. The whole list is 41 requirements from 114 job posts, with the gaps at the same size as the wins.