Small tool to break workflows

Feedback
1

Hi everyone,

I built a small tool to break workflows and find problems outside the happy path.

It takes an exported n8n workflow, one valid webhook payload and the URL of an isolated test copy.

It then generates and executes scenarios such as:

  • missing and null fields;
  • wrong value types;
  • unexpected fields;
  • malformed JSON;
  • concurrent duplicate events.

It correlates the resulting n8n executions and checks whether external action nodes were reached or completed. The report groups failed resilience scenarios into root causes and adds severity and remediation suggestions.

I originally built it for one of my own support workflows. It sent the same event 10 times concurrently: all 10 executions appended a Google Sheets row and 6 created Gmail drafts before the remaining executions hit an OpenAI rate limit.

The workflow looked fine during normal testing, but its duplicate removal logic was not atomic across concurrent executions.

It runs locally, has no telemetry and does not send workflow data to a hosted backend. Analyze and generate are completely offline. A full campaign requires an isolated n8n workflow and a temporary API key to read matching execution traces.

It is still an early and heuristic tool. It is not a security scanner, and dependency failure injection is still experimental.

Repository: GitHub - Smekkamite/break-my-workflow: A small local tool that tries to break n8n webhook workflows · GitHub

Release v0.1.3: Release Break My Workflow v0.1.3 · Smekkamite/break-my-workflow · GitHub

Any feedback is welcome and I’d be especially interested in false positives, confusing results or failure cases it misses. Obviously I don’t need anyone’s workflow, payload or credentials: just a result summary is enough!

Cheers!

2

Your list is the input side and it is the half most people skip. One thing worth adding: after your bad payload makes a branch not match, check whether the skip left a record anywhere. Mine did not. The enum value for a skipped step had existed in my codebase since the first commit and had never once been written, so a skipped step created no database row and the run still finished COMPLETED.

Your tool would have generated that case perfectly and my engine would have said nothing.

3

This is exactly the kind of blind spot I was hoping people would point out! I should add a check for this case ^^

Thanks for the feedback!