NoCrash is now an approved n8n community node: a design audit that scores how well each workflow is built, out of 100

Built with n8n
1

Disclosure first: I am the founder of NoCrash, so this is my own node and I am after honest feedback, not a sales pitch.

Why I built it: most of the reliability trouble I see with client automations is not exotic, it is the same structural gaps left in during a fast build. A workflow ships, works in the demo, and weeks later someone notices it never had an error branch, the flaky HTTP node was never set to retry, and nothing would have told anyone when it broke. I wanted a way to see those gaps before a client does, right inside n8n.

What the audit shows: the default operation, Audit my n8n, reads how each workflow is built and scores it out of 100. It flags the fragile-by-design stuff: a missing error branch, no retry where the call clearly needs one, no alert path, a Schedule trigger with nothing confirming it actually fired. You get a per-workflow number and the specific reasons it lost points.

The honest part, because the naming could oversell it: the free Audit my n8n is a DESIGN check only. It scores how a workflow is BUILT, it does NOT sit and catch a run that quietly failed at 3am. Catching live silent failures is the connected side of the product, a separate thing. I would rather say that plainly than have you install it expecting runtime catching. The other two operations, Heartbeat and Report Failure, are for wiring a workflow to report in from that connected side.

On trust, since it reads your setup: it runs inside your own n8n with your own read-only key, credentials are stripped locally before anything leaves, and workflow definitions are never stored.

Install inside n8n: Settings > Community Nodes > Install > n8n-nodes-nocrash

If you want to run the same design scoring on a pasted workflow JSON without installing the node, the free grader does it in the browser: n8n Workflow Grader — is your workflow safe to run? | NoCrash

I would really like feedback from people running client work: what would you want a build-quality score to flag that it does not yet, and does scoring design separately from live behaviour match how you judge whether a workflow is production-ready?

2 Likes
2

The missing-error-branch and no-retry checks are the ones that bite client builds the most - those failures are silent until something important breaks. Running this as a pre-delivery step before handing off a workflow to a client is a clean idea. One thing I’d be curious about: does the audit check for sticky notes or workflow documentation, or is it purely structural/connectivity checks?

2 Likes
3

That is exactly the split I care about, so let me be straight about the boundary. Right now it is purely the reliability-structural side: does a node have an error branch, is retry set where a call can fail, does an HTTP node have a timeout, is there an alert path, is a Schedule trigger wired to something that actually confirms it fired. It does not grade documentation, so sticky notes and notes on nodes do not move the score today.

I left documentation out on purpose, because a well documented workflow can still fail silently and a messy one can be solid, and I did not want readability inflating a reliability number. That said, a separate maintainability read (documentation, naming, sticky-note coverage) is a fair thing to want, especially for a client handoff. Would you want that as its own score sitting next to the reliability one, or baked into a single grade?

1 Like