Make vs n8n: Which One I'm Still Running

Sixty-five workflows. None of them were running. That was the first thing the audit told me. The second thing it told me was that I hadn't noticed.

I'd been running n8n at krosebrook.app.n8n.cloud across multiple build phases, content pipelines, lead capture, newsletter triggers, CRM sync. All sixty-five were marked active in the dashboard. A Python script that parsed all sixty-five JSON exports pulled name, status, node count, trigger type, and execution history. It ran in a few seconds. The execution column came back zero across every single workflow.

How many I had, how many were running, how many were worth keeping.

The Silent Stack

Zero executions, active flag on, no errors logged. The obvious reading is that something broke. Nothing had.

The workflows weren't failing. They were idle. Triggers configured correctly and never fired, because the downstream conditions they waited on had either never been fully wired or had stopped occurring weeks earlier. n8n's dashboard showed sixty-five green indicators and nothing else. To see execution history, you open each workflow individually. Across sixty-five workflows, that's sixty-five manual checks I wasn't doing.

A broken tool gives you something to fix. An idle tool with an active label gives you nothing until the day you need the workflow to have run and find it hasn't.

A process inspector on the QC floor checks the defect gauge. The gauge reads normal. The defect rate has been climbing for a week. The gauge is accurate about what it measures. Nobody wired it to the defects.

What Triggered the Audit

CVE-2026-33663 landed on the instance. That forced the decision: patch or migrate. I ran the Python audit to figure out which was worth doing.

The CVE got me to look. The zero-execution data decided it: patching an instance that runs nothing means maintaining a vulnerability for no benefit.

The same week, the n8n MCP connector had been in a CONNECTION_ISSUE state throughout recent sessions, couldn't introspect the instance, couldn't read scenario state, couldn't do anything useful from Claude. That was a token scope problem in theory. In practice, it was a second signal in the same direction: the tool I'd built around was invisible to the automation layer that was supposed to manage it.

Make had the same scope issue during initial setup. Its MCP returned "No approval received" on scenario writes. The difference: that error message said exactly what was wrong and exactly where to fix it (Profile → API → regenerate key). I fixed it in ten minutes. The n8n MCP connection was never fixed in the session. I stopped trying and ran the audit instead.

What Survived

The audit classified every workflow:

Forty-three workflows archived or deleted. Most of the migration turned out to be an inventory.

The nine P1 workflows became Make blueprints, properly this time, with error handling and tested endpoints. Two are live now: the lead capture automation for audit.abstrekkt.com and the newsletter trigger for this series. The rest are queued behind Make's free-plan ceiling: two active scenarios, a thousand operations a month.

I first read that ceiling as a constraint. It also makes a sixty-five-workflow silent stack impossible. You can't accumulate a silent stack when you're capped at two active scenarios. The limit forces the inventory discipline that unlimited workflows left to self-governance. I had sixty-five workflows because nothing stopped me from adding the sixty-fifth one. Make stops you at three.

What n8n Still Owns

The migration isn't a verdict on n8n as software.

For complex branching workflows, conditional logic across six or seven states, JavaScript code nodes that do real data transformation, n8n's visual builder handles it more cleanly. Make's scenario structure gets unwieldy when the decision tree is deep enough. n8n's code node is also more capable than Make's built-in functions for anything that requires actual data manipulation beyond simple field mapping.

The self-hosted option matters too. A self-hosted n8n instance with proper monitoring, a cron job that checks execution counts and pages you on zero-run active workflows, would have caught the problem I'm describing here before it became sixty-five workflows deep. What failed was the monitoring I never put on top of it.

If the stack runs a hundred or more active workflows, the calculus is different. Make's per-operation pricing at scale is worse than n8n's flat subscription. The two-scenario cap forces painful prioritization decisions that a larger automation load can't absorb. At that point, n8n's power matters more than its monitoring gaps.

At ten or fewer active workflows, the cap is the right answer.

For me, the better tool is the one whose failures I can read at 2am without opening the documentation.