What the report actually looks like
Most people asking about a review want to know one thing: what do I get at the end of it? This is the answer, at full length, on a workflow built for the purpose.
The synthetic scenario
An end-of-day routine, run by hand, that reshapes enquiry records and posts them to a CRM. Six nodes. It is deliberately ordinary: the interesting thing about it is not its complexity but that everything below is visible in its export, before it ever runs again.
1. The executive summary, in full
Written for the person who owns the business outcome, not the code. This is the whole of it — not an extract.
Your end-of-day routine posts enquiries to your CRM. If anything goes wrong part-way through a run — a malformed record, the CRM being briefly unavailable, an expired key — the run stops where it is, and everything after the failure point is simply not posted. Nothing raises an alarm, nothing writes the failed record anywhere, and nothing tells you which records made it and which did not. The next morning the workflow looks like it ran. Your CRM is missing records nobody counted.
Four things drive that, and they are independent of each other:
- Your export still carries a parameter whose name looks like an API key. If that value is real, then every copy of this file — the one you sent me, the one in your backups, the one in a colleague’s downloads folder — is a copy of a working credential. This is the only finding whose consequences reach outside the workflow, and the only one with an action that cannot wait for a fix cycle.
- One step converts text into structured data in a way that fails hard on anything unexpected. One bad record does not get skipped. It stops the whole run.
- The step that talks to your CRM has nowhere to send a failure. Network blips, authentication problems and CRM-side errors all have the same outcome: the run halts and the record in flight is not written anywhere.
- Nothing anywhere in this workflow handles a failure. No error branch, no error trigger, no error workflow named in the file.
What none of this establishes: that you have actually lost a record. I cannot see that from an export and I do not claim it. Whether any of these paths has ever been taken lives in your n8n execution history, which is not in the file you sent.
What narrows the risk, stated because it is in your favour. The only entry point in this export is a manual trigger, and the workflow’s active flag is false. Nothing fires this on its own. Someone is present every time it runs, which means a stopped run is at least observable by a human who was already looking — it is just not reported. If this workflow is ever moved behind a schedule or a webhook, every severity goes up. That is the single change most likely to turn a manageable set of gaps into an outage nobody sees.
Notice what that section does twice: it says what the evidence cannot support, and it volunteers the fact that makes the situation less alarming. A report that only ever argues in one direction is a sales document with severity labels on it.
2. What the full report contains
| Executive summary | The above. Business terms, no jargon |
|---|---|
| Scope | Exactly what was reviewed, and what was not |
| Method | What static analysis means here, and the statement that your workflow was never executed |
| Findings | Ranked by business impact, which is not the tool's severity order — and where the two differ, the reason is argued |
| CHECKED and NOT CHECKED | Stated as plainly as each other |
| Remediation plan | Kept in its own section, because a finding is observed and a recommendation is judgement |
| Test plan | What to check after fixing, with pass conditions |
| Limitations | What evidence would change the answers, and why execution history is the only thing that can |
| Next actions | With an owner and a date against each |
| Appendix | How to reproduce the report yourself against your own export |
3. One finding, in the format they all use
Finding 1 — An API-key-shaped parameter is still populated in the export
Tool severity: HIGH. My ranking: first.
Status: observed by inspection, not reproduced.
What it is. The export contains a parameter on one node whose key name matches a secret pattern, and whose value is a string. The tool reports the key name and the fact that a string is present. It does not read the value — not to check it, not to measure it, not to hash it.
Why it is ranked first, above three availability findings. This is the only finding whose blast radius leaves the workflow. Every other problem here costs you records inside a system you control. This one is a credential sitting in a file that has already been emailed at least once — to me. Rotation cannot wait for a fix cycle.
What it does not prove. Whether the value is a real secret or a placeholder. Deciding that would require reading it, which the tool will not do. If it turns out to be a placeholder this finding drops to INFO and the ranking above is wrong — that is a two-minute check on your side and it is the first thing in Next Actions.
Every finding carries those four parts: what it is, what happens because of it, what it does not prove, and why its severity is what it is. Where my ranking differs from the tool’s, the report says so and argues it rather than quietly reordering.
4. The part most reports leave out
The report has a section listing what was not checked, at the same level of detail as what was. In the sample it runs to more than a dozen items: no expression was evaluated, no Code node was executed, no credential value was read, instance configuration is not in an export, runtime history is not in an export, and so on.
That section exists because the alternative is worse. A report with no not-checked list quietly implies total coverage, and total coverage is never true. If you have ever received an audit that found eleven things and implied those were all the things, you have read the other kind.
5. What a real engagement adds
This sample is on a synthetic workflow, so two things are missing that a real one has:
- A hand-written reproduction for any finding that sits in your own Code-node logic — written against your source and the input that breaks it, with the output of that run included. Structural findings stay labelled observed by inspection even in a real engagement, because that is what they are.
- Your execution evidence, if you share it. It is optional, and it is the only thing that can turn “this path can fail” into “this path did fail, on these dates”.
Want one of these on your workflow?
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.
Describe your workflow → Email. No form, no signup.
And before you send any export anywhere — to me or to anyone — open it and search it for keys. Finding 1 above is the most common real problem in this whole category, and it is the one that costs something outside your own systems.