I kept seeing the same thing with n8n. People build a workflow, test the happy path once, flip it on, and then something weird happens in production. Duplicate webhook. Missing field. Stripe retry. Suddenly you emailed half your list twice or charged someone wrong.
So I built Crash Labs.
You paste your n8n workflow JSON. It runs it against a fake company (mock email, Stripe, Slack, etc). Then it shows the blast radius. What would have been sent, charged, created. Pass / warn / fail.
It is early. Not every node is covered yet. Coverage and blind spots are in the report so it does not pretend it proved more than it did.
If you build client automations or anything that touches money / customers, try dumping a workflow in and tell me what it gets wrong.
This is a genuinely different problem than the “should this action be allowed” question most of these threads chase, and it’s the one most people skip until it bites them. Pre-deploy blast-radius simulation and runtime policy enforcement solve two different halves of the same fear (duplicate charge, wrong email) — yours catches it before the workflow ever goes live, mine (a policy/audit layer I’ve been building for n8n) catches it while it’s actually running in production, for the stuff a simulation can’t fully predict because the real inputs haven’t happened yet.
Honestly haven’t run my own workflow through Crash Labs yet, but reporting coverage and blind spots alongside the result instead of just pass/fail is the right call — a stress tester that hides its own gaps is worse than no stress tester. Going to actually try dumping my Autopilot workflow in and see what it finds. If you ever want a look at what happens to something after it clears your check and goes live, happy to compare notes.