Every step was green. Nothing landed.
And you found out eleven days later, because a customer asked. I review one exported n8n workflow and tell you which of its silent failure paths actually matter — then show you what I checked, what I didn’t, and what each finding does not prove.
For teams already running n8n in production — agencies, operations teams, and the person who owns the automations but not the time to re-read them.
Describe your workflow → Email. No form, no signup, no newsletter.
Not ready to talk to anyone? The 18-point reliability checklist is the same thing I look for, published in full. Free, no signup — and if you work through it yourself you probably don’t need me.
The failure this is about
It almost always has three parts, and people tell it in this order:
Every node was green. Nothing actually landed in the destination. And nobody found out for days, until a human asked a question.
The first two are the bug. The third is the cost. A failure that announces itself is a bad afternoon; a failure that reports success is a fortnight of decisions made on data that was never there, and a reconciliation afterwards that nobody budgeted for.
It is hard to chase because nothing went wrong in a way n8n can see. A node returned a clean 200. A payload shape changed upstream and a mapping quietly produced nothing. A duplicate check passed twice because two executions overlapped. The execution list shows green runs, so there is no error to search for and no failed run to open.
Every one of those is visible in the workflow’s own export, before anything runs. That is what this review reads.
What it is, in three lines
- You send the workflow export and say what it’s for.
- I review it — deterministic static analysis of the export, plus judgement about your business.
- You get ranked findings, what each does not prove, recommended fixes kept separate, and a NOT CHECKED list.
The deliverable is a report you can verify without trusting the person who wrote it. That is the product. The tooling underneath it is not the point — and I would rather say why than let you find out.
Reading the file is the easy part, and it is getting cheaper
Free tools exist that will take a workflow export and hand you a list of places it could fail. Some are good. If a list is what you need, use one and keep your money.
A list is not the hard part. The hard part is the three things a list does not do: telling you which two of eleven findings are worth your week, stating plainly what was not examined, and refusing to claim something has failed when the evidence only shows it can. The last one matters most, because a tool that only ever argues in one direction will eventually cost you a sprint on a problem you never had.
That judgement is what I sell. Not the reading.
It works on the first day
Monitoring and anomaly detection need a baseline — weeks of your normal behaviour before they can tell normal from wrong. That is fine if the workflow has been running for months and nothing has changed.
Reading the export needs none of that. It works on a workflow you shipped this morning, on one you inherited from someone who left, and on one you are about to put ten times the volume through. Those are exactly the three moments when the risk is highest and a baseline does not exist yet.
Three properties that are the actual product
- Nothing from your export is ever executed. No node runs, no request is made, no credential value is read. Code nodes are inspected as text.
- No parameter value or Code-node body appears in the report — a blanket rule rather than a filter, because a filter is a list of the leaks somebody thought of.
- Every finding carries what it does not prove. “This contains an unhandled failure path” and “this has failed” are different claims. An export only supports the first.
What gets checked, from the export alone
Node inventory and connection graph; triggers; Code-node structure; nodes that can fail with nowhere to send the failure; paths that end recording nothing; the non-atomic static-data idempotency pattern; isolated and unreachable nodes; unwired Merge inputs; webhook triggers with no authentication; credential references; secret-shaped parameter keys; and unrecognised node types.
Who this is for — and who it isn’t
| A good fit | You run n8n in production. Something has gone quietly wrong at least once, or you are about to put more volume through a workflow than it has carried before. Someone can approve a small fixed-price piece of work. |
|---|---|
| Not a fit — and I’ll say so | You are on Make, Zapier or Power Automate only. I have not built the evidence to review those and will not pretend otherwise. You want the workflow fixed rather than reviewed — that is a different job. You want an ongoing retainer as a first engagement. |
What it is not, and cannot become
Stated here rather than discovered later, because a review that overstates its reach is worse than no review — it spends your engineers’ time on work that was never needed.
- It is not “we reproduce your workflow end to end”. Your workflow is never run. There is no n8n execution engine here and none is planned.
- No n8n expression is evaluated. A wrong expression is invisible to static analysis.
- No Code node is executed. Code-node findings are lexical — the source is read as text.
- Nothing is said about your credentials. Only the reference is read, so nothing establishes whether one is valid, expired or over-scoped.
- Instance configuration is not in an export. A global error workflow, timeouts, queue mode, concurrency settings and your n8n version can all change the conclusions.
- Runtime history is not in an export. Nothing derived from a file says how often a path has actually been taken.
- Where a finding cannot be reproduced, it is reported as observed by inspection, not reproduced — and labelled that way. A finding you cannot reproduce is withdrawn, not defended.
A worked example
Rather than a case study, which would need a client I have not had, here is the method applied to a workflow of my own — a lead-intake deduplication that passed every test for a full session and was never a dedupe at all. It ends at the finding, not at an offer.
Questions people actually ask
Who have you done this for?
Nobody yet. This business was registered on 15 September 2026 and has had no clients. I could have waited and said nothing, but you would have found out, and a first engagement built on a vague impression is worse for both of us. What exists instead of a client list is a method you can inspect: the teardown is a real defect found in my own work, including the part where my own tests passed for a whole session and were measuring the wrong thing.
What do I actually send you?
To start, just a description — what the workflow does, what should happen, and anything odd you have noticed. The export comes later, with credential values stripped. Please don’t email credentials, API keys, tokens or passwords at any point. If one arrives anyway I will tell you immediately and treat it as exposed, because deleting an email is not the same as rotating a key.
What does the report look like?
There is a full sample review on the site — a real analysis run against a synthetic workflow, with the executive summary and one finding at full length. It is the quickest way to see whether this is the kind of thing you want.
What if you don’t find anything?
Then I say so, and that is a real result rather than a failed engagement. A review that always finds something is not a review.
How long does it take?
Days, not weeks — and I will give you a date once I have seen the workflow rather than before. I would rather commit to something I can hold than to something that sounds impressive.
What does it cost?
A fixed price, agreed before any work starts, and small enough to be an expense approval rather than a budget decision. I quote it in the first conversation, once I know the workflow is one I can actually help with.
Are you a real business I can invoice through?
Yes — a registered Slovenian s.p., paid by bank transfer, with the full register details in the footer. That matters more than it sounds: much of the cheap end of this market settles in crypto to an anonymous handle, which an accountant cannot book.
Can you just fix it instead?
Not as the first piece of work. An audit that fixes things is not an audit — mixing them makes both unverifiable. If the findings justify a fix, we scope that separately afterwards.
Talking to me
Tell me what the workflow does and what you think is going wrong. If it is not something I can genuinely help with, I will say so in the first reply — that is the outcome that makes the rest of this page credible.
Describe your workflow → Opens your mail app with the questions pre-filled.
Please don’t send secrets. No credentials, API keys, tokens or passwords — not in the first email and not in the export. There is nothing I need that requires them.